On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
<k.knizhnik@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