Robert Haas <robertmh...@gmail.com> writes: > On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: >> Well, it solves the case people have actually complained about (twice >> now). I originally attempted to solve a larger set of cases, but it's >> not clear there's enough value in that.
> How related is this issue? > http://archives.postgresql.org/pgsql-hackers/2008-12/msg00369.php It's not the same thing --- the detoast calls here seem to be associated with examining pg_statistic entries in the planner. It's hard to tell from this whether the detoastings are repetitive, or how much we might stand to gain if they are (the test case doesn't seem to have run long enough to make the timings trustworthy). I'll just note that my previous proposed patch http://archives.postgresql.org/message-id/5184.1214773...@sss.pgh.pa.us wouldn't have helped this case either, since that was purely an executor patch. The generic backend-wide cache I suggested originally might have helped, but implementing that seems daunting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
