On 2017-11-08 12:02:40 -0500, Tom Lane wrote:
> BTW, it strikes me that in considering the rebuild-the-page approach,
> we should not have blinders on and just measure the speed of
> PageRepairFragmentation. Rather, we should take a look at what happens
> subsequently given a physically-ordered set of tuples. I can recall
> Andres or someone moaning awhile ago about lack of locality of access in
> index page searches --- maybe applying that approach while vacuuming
> indexes will help?
I complained about multiple related things, I'm not exactly sure what
exactly you're referring to here:
- The fact that HeapTupleHeaderData's are commonly iterated over in reverse order is bad for performance. For shared
buffersresident workloads involving seqscans that yields 15-25% slowdowns for me. It's trivial to fix that by just
changingiteration order, but that obviously changes results. But we could reorder the page during heap pruning.
But that's fairly independent of indexes, so I'm not sure whether that's what you're referring.
- The layout of items in index pages is suboptimal. We regularly do binary searches over the the linearly ordered
items,which is cache inefficient. So instead we should sort items as [1/2, 1/4, 3/4, ...] elements, which will access
itemsin a close-ish to linear manner.
But that's fairly independent of pruning, so I'm not sure whether that's what you're referring to, either.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers