On 04/08/2014 08:02 PM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 3:12 AM, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
1. Avoid fmgr and shim overhead
2. Use strxfrm to produce a pseudo-leading key that's cheaper to compare.
In that case, these changes need to be analyzed separately. You don't get to
"make up" for the losses by the second part by the gains from the first
part. We could commit just the first part (for 9.5!), and that has to be the
baseline for the second part.
Yes, that's right. Robert already submitted a patch that only did 1)
almost 2 years ago. That should have been committed at the time, but
wasn't. At the time, the improvement was put at about 7% by Robert. It
would be odd to submit the same patch that Robert withdrew already.
Why shouldn't 2) be credited with the same benefits as 1) ? It's not
as if the fact that the strxfrm() trick uses SortSupport is a
contrivance. I cannot reasonably submit the two separately, unless the
second in a cumulative patch.
Sure, submit the second as a cumulative patch.
By far the largest improvements come
from 2), while 1) doesn't regress anything.
Right. But 1) is the baseline we need to evaluate 2) against.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
