| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Date: | 2014-08-14 19:52:26 |
| Message-ID: | CAM3SWZQggiK1SH=9-e7jAzb9BrKSGw2JpHiYkO5LxzbPnrWipQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 14, 2014 at 11:55 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Clearly there are still benefits to be had for cluster and B-Tree
> tuplesorts.
In a world where this general support exists, abbreviated keys could
be made to work with both of those, but not datum tuplesorts, because
that case needs to support tuplesort_getdatum(). Various datum
tuplesort clients expect to be able to retrieve the original
representation stored in SortTuple.datum1, and there isn't much we can
do about that.
This is a bit messy, because now you have heap and datum cases able to
use the onlyKey qsort specialization (iff the opclass doesn't provide
abbreviated key support in the heap case), while all cases except the
datum case support abbreviated keys. It's not that bad though; at
least the onlyKey qsort specialization doesn't have to care about
abbreviated keys, which makes sense because it's generally only
compelling for pass-by-value types.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-08-14 19:59:49 | Re: replication commands and index terms |
| Previous Message | Tomas Vondra | 2014-08-14 19:47:58 | Re: 9.5: Memory-bounded HashAgg |