| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | amborodin(at)acm(dot)org |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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 21:08:19 |
| Message-ID: | 17829.1473455299@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
... BTW, a quick grep for other calls of PageIndexTupleDelete suggests
that SPGiST could make very good use of PageIndexTupleOverwrite, and
there may be use for it in GIN too.
I see one place in btree where there's a PageIndexTupleDelete and then
an insert, but it's unlikely to be worth touching because the page is
expected to be empty after the PageIndexTupleDelete; so there's no
data movement we could avoid in that case.
I don't plan to investigate these cases myself, but somebody should.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-09-09 21:15:31 | Re: More ideas for speeding up sorting |
| Previous Message | Peter Geoghegan | 2016-09-09 21:01:14 | Re: More ideas for speeding up sorting |