Re: Reducing overhead for repeat de-TOASTing - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reducing overhead for repeat de-TOASTing
Date
Msg-id 1213798053.9468.132.camel@ebony.site
Whole thread Raw
In response to Re: Reducing overhead for repeat de-TOASTing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing overhead for repeat de-TOASTing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2008-06-18 at 09:45 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > You've not covered the idea that we just alter the execution so we just
> > detoast once.
> 
> That's because I already considered and rejected that idea.  There's
> no very good place to do it.  See thread on postgis-devel:
> 
> http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003091.html
> 
> Aside from the problems mentioned there, there's the issue that a lower
> plan level doesn't have any way to know whether the value will be needed
> at all.  We could look for references to the Var but it's entirely
> possible that the Var is being passed to some function that doesn't
> require a fully detoasted result.  It wouldn't do for this
> "optimization" to disable the slice-fetch feature...

Agreed. Yet I'm thinking that a more coherent approach to optimising the
tuple memory usage in the executor tree might be better than the special
cases we seem to have in various places. I don't know what that is, or
even if its possible though.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reducing overhead for repeat de-TOASTing
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] Hint Bits and Write I/O