Prev: security label support, part.2
Next: SQL/MED security
From: Robert Haas on 22 Jul 2010 15:03
On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
<vamsikrishna1902(a)gmail.com> wrote:
> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
> set B={6,7,8,9,10}.
>
> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.

I don't think that makes any sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 27 Jul 2010 16:24
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
> <vamsikrishna1902(a)gmail.com> wrote:
>> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
>> set B={6,7,8,9,10}.
>>
>> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.

> I don't think that makes any sense.

Yeah. The theoretical problem is that substituting setB for setA could
change the estimated rowcounts, and thus you should not use the same
path. The practical problem is that the Path datastructure doesn't
store the specific quals to be used, in general --- it relies on the
RelOptInfo structures to remember which quals need to be checked during
a scan. So you can't just "copy the path and substitute some other
qual". You could maybe do it if you copied the entire planner
workspace, but that's not too practical from a memory consumption
standpoint. Not to mention that a lot of the node types in question
don't have copyfuncs.c support, which is only partly laziness --- it's
also the case that copyObject() is incapable of coping with circular
linkages, and the planner data structures are full of those.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: security label support, part.2
Next: SQL/MED security