Re: [HACKERS] TIME QUALIFICATION

From: jwieck(at)debis(dot)com (Jan Wieck)
To: vadim(at)krs(dot)ru (Vadim Mikheev)
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] TIME QUALIFICATION
Date: 1999-02-11 18:55:15
Message-ID: m10B1Gd-000EBRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Do you mean subselect.c:147 line:
>
> slink->subselect = NULL; /* cool ?! */
>
> ?

Exactly that!

>
> As I remember this is done to don't copy subquery' Query
> node in copyObject when copying plan. Actually, using
> Query node in Executor is annoying me for ~ 1 year:
> Executor need not in entire Query node, only in range table!
> Using Query in Executor is bad for prepared plans: we do
> copying and storing of mostly useless Query node...
> This would be nice to have some new TopPlan node with
> upmost plan, range table and some other things (I had to
> add some fields to Plan node itself for subqueries while
> these fields should be only in topmost plan node) and get rid
> of using Query in Executor. Query is result of parsing,
> plan is result of planning and source for execution.
>
> If you don't want to implement TopPlan node then you could
> allocate new SubLink node in subselect.c:_make_subplan()
> to be used in node->sublink...

Ah - I see.

So I assume the sublink->subselect, that's copied into the
plan, is totally obsolete too at that point. The subplan has
it's own rangetable, which is the same as the (not used) one
in the subselect.

I think I should tidy up that all to finally pass only plan
into executor before going ahead with the deferred query
stuff. It doesn't make sense to spend much efford now to
prepare the system for deferred queries. It depends too much
on where the RTE's are and how we organize them.

New TopPlan could be passed down the executor instead of
querytree. It might hold a List of rangetables. Plan and
SubPlan then have an index telling which nth() rangetable of
TopPlan to use for it.

This would make execution preprocessing for snapshot->RTE
assignment very easy because there's only one place to find
ALL RTE's (no need to traverse down a tree). And it would
substantial lower the amount of data to copy in SPI, since it
must not save the Querytree at all.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 1999-02-11 19:03:48 Re: [HACKERS] Re: [SQL] RULE questions.
Previous Message Jan Wieck 1999-02-11 18:01:49 Re: [HACKERS] Re: [SQL] RULE questions.