Re: Improving btree performance through specializing by key shape, take 2
От | Peter Geoghegan |
---|---|
Тема | Re: Improving btree performance through specializing by key shape, take 2 |
Дата | |
Msg-id | CAH2-Wz=zNBKRw-CYgbpkk8qmqd34Y_Tyhm2cZ=B6wiAN3PB3HQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improving btree performance through specializing by key shape, take 2 (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Improving btree performance through specializing by key shape, take 2
|
Список | pgsql-hackers |
On Mon, Sep 25, 2023 at 9:13 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > I think it's fairly complete, and mostly waiting for review. > > > I don't have time to do a comprehensive (or even a fairly > > cursory) analysis of which parts of the patch are helping, and which > > are marginal or even add no value. > > It is a shame that you don't have the time to review this patch. I didn't say that. Just that I don't have the time (or more like the inclination) to do most or all of the analysis that might allow us to arrive at a commitable patch. Most of the work with something like this is the analysis of the trade-offs, not writing code. There are all kinds of trade-offs that you could make with something like this, and the prospect of doing that myself is kind of daunting. Ideally you'd have made a significant start on that at this point. > > I have long understood that you gave up on the idea of keeping the > > bounds across levels of the tree (which does make sense to me), but > > yesterday the issue became totally muddled by this high key business. > > That's why I rehashed the earlier discussion, which I had previously > > understood to be settled. > > Understood. I'll see if I can improve the wording to something that is > more clear about what the optimization entails. Cool. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: