On Mon, 2007-11-26 at 18:18 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate