Re: Another try at reducing repeated detoast work for PostGIS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Another try at reducing repeated detoast work for PostGIS
Date
Msg-id 5561.1250535244@sss.pgh.pa.us
Whole thread Raw
In response to Re: Another try at reducing repeated detoast work for PostGIS  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Another try at reducing repeated detoast work for PostGIS  (Jeff Davis <pgsql@j-davis.com>)
Re: Another try at reducing repeated detoast work for PostGIS  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote:
>> Thinking about it again, it seems to me that a much narrower patch
>> could solve the specific forms of the problem that the PostGIS folk
>> are seeing.  Instead of trying to have a general-purpose method of
>> preventing repeat de-toasting, we could just prevent it for inner
>> indexscans by having ExecIndexEvalRuntimeKeys() detoast anything it's
>> passing to the index AM. 

> With this patch, are there still situations where we should be concerned
> about repeated de-toasting, or does this solve the biggest part of the
> problem?

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.

> If so, is it possible that two similar plans for the same query might
> perform differently due to repeated de-toasting?

Hard to answer that one.  What's "similar"?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Alpha 1 release notes
Next
From: Tom Lane
Date:
Subject: Re: Road to alpha1