From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Reducing overhead for repeat de-TOASTing |
Date: | 2008-06-18 14:07:33 |
Message-ID: | 1213798053.9468.132.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2008-06-18 at 09:45 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-06-18 14:32:12 | Re: [HACKERS] Hint Bits and Write I/O |
Previous Message | Simon Riggs | 2008-06-18 13:53:29 | Re: [HACKERS] Hint Bits and Write I/O |