From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | amborodin(at)acm(dot)org, Andrew Borodin <borodin(at)octonica(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Sergey Mirvoda <sergey(at)mirvoda(dot)com> |
Subject: | Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC] |
Date: | 2016-09-09 18:19:23 |
Message-ID: | 552.1473445163@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's a draft patch that replaces BRIN's use of PageIndexDeleteNoCompact
and an immediately following PageAddItemExtended with
PageIndexTupleOverwrite. It turns out that there are two use-cases in
BRIN for PageIndexDeleteNoCompact, and the other one can't be replaced
because while there is a PageAddItem call beside it, that one is for a
different page. But this is still enough to let us get rid of
PAI_ALLOW_FAR_OFFSET, which seems like a good thing.
Actually, with this patch, PageAddItemExtended isn't directly referenced
anywhere, so we could revert that API and fold it back into PageAddItem,
saving a nanosecond or two per call. I'm inclined to leave that alone,
though, since I agree with the underlying thought that any future
extensions to PageAddItem's functionality would be better handled by more
bits in a flags bitmask. Maybe a better idea is to get rid of the call
overhead by turning PageAddItem into a macro. In any case, doing
something about that could be a separate patch.
It's also kind of tempting to rewrite PageIndexDeleteNoCompact into a
function that only deletes one tuple, and presumably is simpler and faster
than what's there. But maybe there's something coming down the pike that
needs the extra generality? That should also be a separate patch, anyway.
This passes make check-world but I'm not sure how heavily that stresses
BRIN ... are there any other tests you'd want to see run before
committing?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
use-PageIndexTupleOverwrite-in-BRIN.patch | text/x-diff | 10.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2016-09-09 18:40:59 | Re: GiST penalty functions [PoC] |
Previous Message | Tom Lane | 2016-09-09 17:59:24 | Re: Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn |