On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > I agree with your that loosing sequential order of B-Tree pages may have > negative impact on performance. > But it first of all critical for order-by and range queries, when we > should traverse several subsequent leave pages. > It is less critical for exact-search or delete/insert operations. > Efficiency of merge operations mostly depends on how much keys > will be stored at the same B-Tree page.
What do you mean by "mostly"? Given PostgreSQL has quite small (8k) pages, sequential read in times faster than random read on SSDs (dozens of times on HDDs). I don't think this is something to neglect. > And it is first of all > determined by size of top index and key distribution. How can you be sure that the top index can fit memory? On production systems, typically there are multiple consumers of memory: other tables, indexes, other LSMs. This is one of reasons why LSM implementations have multiple levels: they don't know in advance which levels fit memory. Another reason is dealing with very large datasets. And I believe there is a quite strong reason to keep page order sequential within level. I'm OK with your design for a third-party extension. It's very cool to have. But I'm -1 for something like this to get into core PostgreSQL, assuming it's feasible to push some effort and get state-of-art LSM there. ------ Regards, Alexander Korotkov