Re: B-Tree support function number 3 (strxfrm() optimization)

On Tue, Apr 8, 2014 at 3:10 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Apr 8, 2014 at 10:10 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> Right. But 1) is the baseline we need to evaluate 2) against.
>
> I don't agree with that. Surely we're concerned with not regressing
> cases that people actually care about, which in practical terms means
> the changes of a single release.

No, we're concerned about ending up with the best possible
performance.  That could mean applying the fmgr-elision but not the
other part.  Whether the other part is beneficial is based on how it
compares to the performance post-fmgr-elision.

As an oversimplified example, suppose someone were to propose two
patches, one that makes PostgreSQL ten times as fast and the other of
which slows it down by a factor of five.  If someone merges those two
things into a single combined patch, we would surely be foolish to
apply the whole thing.  The right thing would be to separate them out
and apply only the first one.  Every change has to stand on its own
two feet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company