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. +
