On 8/10/16 12:48 PM, Claudio Freire wrote:
On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
On 8/9/16 6:44 PM, Claudio Freire wrote:
Since we can lookup all occurrences of k1=a index=0 and k2=a index=0,
and in fact we probably did so already as part of the update logic
That's a change from what currently happens, right?
The reason I think that's important is that dropping the assumption that we
can't safely re-find index entries from the heap opens up other
optimizations, ones that should be significantly simpler to implement. The
most obvious example being getting rid of full index scans in vacuum. While
that won't help with write amplification, it would reduce the cost of vacuum
enormously. Orders of magnitude wouldn't surprise me in the least.
If that's indeed a prerequisite to WARM it would be great to get that
groundwork laid early so others could work on other optimizations it would
enable.
I can do that. I've been prospecting the code to see what changes it
would entail already.
But it's still specific to btree, I'm not sure the same optimizations
can be applied to GIN (maybe, if the posting list is sorted) or GIST
(probably, since it's like a btree, but I don't know the code well
enough).
Certainly hash indexes won't support it.
Why not? If this is all predicated on re-finding index keys based on
heap data then this is just another index lookup, no?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
