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.
regards, tom lane
