From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Another try at reducing repeated detoast work for PostGIS |
Date: | 2009-08-17 19:42:38 |
Message-ID: | 6483.1250538158@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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.1214773030@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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-17 19:52:20 | Re: Alpha 1 release notes |
Previous Message | Josh Berkus | 2009-08-17 19:42:10 | Re: Alpha 1 release notes |