Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [SQL] cursor and update + view

From: jwieck(at)debis(dot)com (Jan Wieck)
To: vadim(at)krs(dot)ru (Vadim Mikheev)
Cc: jwieck(at)debis(dot)com, s-fery(at)kkt(dot)sote(dot)hu, pgsql-sql(at)postgreSQL(dot)org, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [SQL] cursor and update + view
Date: 1998-11-25 10:37:04
Message-ID: m0zicJk-000EBQC@orion.SAPserv.Hamburg.dsh.de (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-sql
Vadim wrote:

>
> Jan Wieck wrote:
> >
> >     If  we put any view into a subquery RTE, we force the planner
> >     to materialize the  view  and  do  a  nestloop  over  t3  and
>          ^^^^^^^^^^^
> Do you mean creating some tmp table etc?
> No - it's not required.

    Sometimes  a  sortset  is  required (grouping, nesting etc.).
    With materialize I meant the same thing the executor does for
    a scan, merge or iter node. They return in memory tuples from
    a relation or a temp file. In our new case  it's  mostly  the
    same as a scan node that does the view selection inside.  And
    it returs the same tuples as a SELECT * from the view  would.
    That's internal, on the fly materialization of the view.

> On the other hand, as we talk about query optimization - why
> rule system should do optimizer' work? Why not just put
> _any_ VIEW' query into FROM and let optimizer decide
> could query be rewritten as join or not? Ppl do strange
> things sometimes -:) Sometimes they use subqueries in
> WHERE while joins could be used and our optimizer don't
> try to catch this. I know that Sybase does.
> And, imho, we should implement this ... sometime -:))

    Depends on where the optimization is done. If we do it on the
    parsetree (Query struct), it's the job of  the  rule  system.
    The optimizer does not have to modify the parsetree. If it is
    done on the way from the parsetree to the plan, it is the job
    of the optimizer.

    If  it  is  possible to do it on the parsetree, I would do it
    there.


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

pgsql-hackers by date

Next:From: Jan WieckDate: 1998-11-25 11:08:46
Subject: LIMIT patch available (was: Re: [SQL] MINUS and slow 'not in')
Previous:From: IntegrationDate: 1998-11-25 06:37:32
Subject: 6.4.x

pgsql-sql by date

Next:From: Jan WieckDate: 1998-11-25 11:08:46
Subject: LIMIT patch available (was: Re: [SQL] MINUS and slow 'not in')
Previous:From: Vadim MikheevDate: 1998-11-25 03:26:42
Subject: Re: [HACKERS] Re: [SQL] cursor and update + view

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group