From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inlining comparators as a performance optimisation |
Date: | 2011-12-07 01:46:27 |
Message-ID: | 1698.1323222387@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Works for me. I think we should go ahead and get this part committed
> first, and then we can look at the inlining stuff as a further
> optimization for certain cases...
Yeah. Attached is a second-draft patch, which I'm fairly happy with
except that the documentation hasn't been updated. It extends the
changes into the executor as well as analyze.c, with the result that
we can get rid of some of the old infrastructure altogether.
(inlineApplySortFunction is still there for the moment, though.)
Also, I adopted a style similar to what we've done for inlined list
functions to make ApplyComparatorFunction inline-able by all callers.
There are three somewhat-independent lines of work to pursue from here:
1. Adding sortsupport infrastructure for more datatypes.
2. Revising nbtree and related code to use this infrastructure.
3. Integrating Peter's work into this framework.
I'll try to take care of #1 for at least a few key datatypes before
I commit, but I think #2 is best done as a separate patch, so I'll
postpone that till later.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
sort-support-3.patch | text/x-patch | 69.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-12-07 02:58:06 | Timing overhead and Linux clock sources |
Previous Message | Peter Geoghegan | 2011-12-07 01:19:24 | Re: pg_stat_statements with query tree based normalization |