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

Reply via email to