Re: 8.3devel slower than 8.2 under read-only load

Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > But I think there must be an action that we can take for 8.3 and that
> > much runtime should not be given away easily. ISTM that we can win back
> > the losses Guillaume has identified, plus gain a little more even.
> 
> Perhaps some sanity could be restored to this discussion by pointing out
> that the 2007-01-01 code *also* clocks in at 37% spent in
> oper_select_candidate.  IOW it's been like this for a very long time.
> I'm not interested in destabilizing 8.3 with panicky last-minute patches.
> 
> > So how about we have a cache-of-one:
> 
> Cache-of-one has exactly the same difficulty as cache-of-many, other
> than the table lookup itself, which is a solved problem (hashtable).
> You still have to determine how you identify the cached value and what
> events require a cache flush.  Nor do I see any particular reason to
> assume that a cache of only one operator would be of any use for
> real-world apps, as opposed to toy examples.

Seems like anytime a function like that takes 37%, there is something
wrong.  Are we sure there isn't a bug in there somewhere?

As far as a cache, could we create a simple cache that remembered the
last X lookups and cleared the cache anytime a cache invalidation
message came in?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +