st 1. 11. 2023 v 11:32 odesílatel Matthias van de Meent < boekewurm+postg...@gmail.com> napsal:
> On Wed, 1 Nov 2023 at 07:47, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > Hi > > > > út 31. 10. 2023 v 22:12 odesílatel Matthias van de Meent < > boekewurm+postg...@gmail.com> napsal: > >> This patch was originally suggested at [0], but it was mentioned that > >> they could be pulled out into it's own thread. Earlier, the > >> performance gains were not clearly there for just this patch, but > >> after further benchmarking this patch stands on its own for > >> performance: it sees no obvious degradation of performance, while > >> gaining 0-5% across various normal indexes on the cc-complete sample > >> dataset, with the current worst-case index shape getting a 60%+ > >> improved performance on INSERTs in the tests at [0]. > > > > > > +1 > > Thanks for showing interest. > > > This can be nice functionality. I had a customer with a very slow index > scan - the main problem was a long common prefix like prg010203xxxx. > > I'll have to note that this patch doesn't cover cases where e.g. text > attributes have large shared prefixes, but are still unique: the > dynamic prefix compression in this patch is only implemented at the > tuple attribute level; it doesn't implement type aware dynamic prefix > compression inside the attributes. So, a unique index on a column of > int32 formatted like '%0100i' would not materially benefit from this > patch. > > While would certainly be possible to add some type-level prefix > truncation in the framework of this patch, adding that would require > significant code churn in btree compare operators, because we'd need > an additional return argument to contain a numerical "shared prefix", > and that is not something I was planning to implement in this patch. > Thanks for the explanation. Pavel > Kind regards, > > Matthias van de Meent > Neon (https://neon.tech) >
