On Mon, 2007-11-26 at 18:18 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Here's where I am:
>
> > Basic test was to replace call to oper_select_candidate with a single
> > item that was fed by a hardcoded value for varchar equality operator.
>
> Well, that confirms what we knew from gprof, but surely you aren't
> proposing that as a usable patch.
gprof might not have translated into a usable gain, but clearly it can.
That's not a proposed patch, just showing my results.
> > What I'm actually proposing is a patch implementing a oper_select_hook
> > function pointer, which allows the user to do anything they want.
>
> Why in the world would that be a good idea?
Short answer: it makes it go faster? You asked. ;-)
Long answer: We all agree the operator cache is the best answer, yet
don't wish to delay the project or make it less robust. The best answer
is a plugin approach that lets users take the risk and make the gain.
We can't hardcode it for everybody because that runs completely against
the grain of Postgres. Including this as a plugin allows people to make
their own decisions about cacheing/hardcoding. If you are the unlucky
owner of a database with a heavy read workload and lots of VARCHAR keys
then you're going to want this.
The plugin allows writing a one-slot cache that is never flushed. If you
choose to override the operators then you'd need to reconnect. It also
allows some performance tuning in other cases too, so having it as a
general case makes sense.
The overhead of implementing it this way is very close to zero and the
code path doesn't even get called in the integers-as-keys cases.
I don't really like all of this, but that much gain is too much for me
to ignore. Better ideas eagerly accepted, and encouraged.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
