jarulraj

Can you please open an issue or send a PR to update the documentation? Thanks!

Thanks for sharing these interesting anecdotes.

Thanks for sharing your perspective. I will add a new check to ensure that table columns are always be prefixed with table name. However, I still think that it is worthwhile to not use a generic primary key name (at least in the common case).

I agree that executing fewer SQL queries is often better for performance.

However, it is possible that an elaborate SQL query that has to use many joins, correlated subqueries, and other operations can be harder for the SQL engine to optimize and execute quickly than a set of more straightforward queries.

Furthermore, these queries are simply hard to write, hard to modify, and hard to debug. I am hoping that these checks would serve as hints to developers to simplify and modularize complex SQL queries.

LMDB is a highly-optimized storage engine. However, it is not a full-featured DBMS (e.g., no support for query optimization). This talk focuses on the potential impact of NVM on different layers of a full-featured DBMS -- not only the storage engine.

That's correct, the DBMS will rely on replication to survive media failures. The "NVM Express over Fabrics" standard is a step along that direction.

http://www.nvmexpress.org/wp-content/uploads/NVMe_Over_Fabri...

Meta-observation: LMDB is a highly-optimized storage engine. However, it is not a full-featured DBMS (e.g., no support for query optimization). This talk focuses on the potential impact of NVM on different layers of a full-featured DBMS -- not only the storage engine.

> The fact that NVRAM is directly addressable (and thus can bypass the page cache) will eventually play out as irrelevant. It will always be a fact that slower mass-storage will exist, more cheaply than fast in-core storage, persistent or not.

Well, it depends on the latency of the NVM device. If the NVM device is directly addressable and has DRAM-like access latencies, I suspect that we must re-examine the assumptions underlying storage virtualization. Although I agree that the OS/DBMS would still need to maintain a page cache for data residing on slow block-addressable SSD/HDDs, I suspect that this will not be the case for data residing on fast byte-addressable NVM.

> Anything that requires logging or any form of compaction or garbage collection is wasted work. It's completely unnecessary, and that has nothing to do with NVM. Treating NVM DB design as if it's an entirely new and different animal is frankly ignorant. The right design works in all scenarios - as LMDB does.

If you think about it, logging is equivalent to versioning. To ensure atomicity and durability, a DBMS must maintain BEFORE and AFTER images of tuples. Unless it is a pure append-only system, the DBMS cannot refrain from reclaiming the storage space associated with OLDER tuple images. Note that these images can be stored either in the log or in multi-versioned heap storage. Maintaining a second B+tree to keep track of free pages, as is done is LMDB, is simply an implementation detail.

Any war stories on the SQL Server Database Engine Tuning Advisor? How significantly has it affected the performance of the system?

Thanks for the shout-out!

Thanks :) We believe that non-volatile memory (NVM) will be a game-changer for database management systems [1].

[1] https://www-ssl.intel.com/content/www/us/en/architecture-and...

That's correct! This is the reason why we support both OLTP and OLAP workloads in Peloton.

We certainly do :) There happens to be an autonomous mechanism for supporting hybrid workloads (OLTP & OLAP). Peloton supports hybrid storage layouts that are automatically and dynamically adapted over time based on the workload patterns. Row and columnar storage types are special cases of hybrid storage layouts. This is a promising area of ongoing research. If you are curious about this kind of autonomous tuning of storage layout, you might want to check this out [1].

[1] https://www.cs.cmu.edu/~jarulraj/papers/2016.tile.sigmod.pdf

Great question! There happens to be an autonomous mechanism for supporting hybrid workloads (OLTP & OLAP). Peloton supports hybrid storage layouts that are automatically and dynamically adapted over time based on the workload patterns. Row and columnar storage types are special cases of hybrid storage layouts.

This is a promising area of ongoing research. If you are curious about this kind of autonomous tuning of storage layout, you might want to check this out [1].

[1] https://www.cs.cmu.edu/~jarulraj/papers/2016.tile.sigmod.pdf

There is on-going conversation on the pg-hackers mailing list. Thanks for the positive feedback.

I see, thanks for sharing this information.

* It is a proof-of-concept implementation to show that porting Postgres over to C++ is feasible with minimal changes. It is not official.

* We need to refactor the increment operator because the variables are of enumeration type.

* We have not yet tested compilation with clang. But, I presume that minimal changes would be required to support compilation with clang. PRs are welcome!

* Not really. Our hope is that the PostgreSQL core team would consider gradually migrating over to C++. I think that this refactoring can be done without breaking external interfaces.

Thanks for the positive feedback.

Whoa, why would you do that ?

Certain features of the C++ language and its library should help simplify coding, improve code reuse, and avoid bugs.

Here's a blog post that provides more context: https://petereisentraut.blogspot.com/2013/05/moving-to-c.htm...