Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
