From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.3devel slower than 8.2 under read-only load |
Date: | 2007-11-27 00:39:17 |
Message-ID: | 200711270039.lAR0dHl08987@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-11-27 00:42:56 | Re: Table inheritance, unique constraints and foreign key problem |
Previous Message | Simon Riggs | 2007-11-26 23:39:10 | Re: 8.3devel slower than 8.2 under read-only load |