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-24 15:50:11
Message-ID: m0ziKjE-000EBYC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Vadim wrote:

> This thing would also handled by subqueries in FROM!
> Having support in planner/executor for queries like this:
>
> select * from A, (select c, max(d) as m from B group by c) SQ
> where SQ.c = A.x and SQ.m = A.y
>
> rule system will be able to put _any_ VIEW' query into
> FROM clause...

Possible - but IMHO the wrong thing to do. As it is now for a
view that has no aggregate, the rule system rewrites the
query to something that is the same as if the user resolved
the view definition by hand and used all the real tables
instead. Have the following:

CREATE TABLE t1 (a int4, b int4);
CREATE TABLE t2 (a int4, c int4);
CREATE TABLE t3 (a int4);
CREATE VIEW v1 AS SELECT t1.a, t1.b, t2.c
FROM t1, t2 WHERE t1.a = t2.a;

Now do a

SELECT t3.a, v1.b, v1.c FROM t3, v1
WHERE t3.a = v1.a;

The current rewrite system builds a querytree that is exactly
that what would have been produced by the parser if you had
typed

SELECT t3.a, t1.b, t2.c FROM t3, t1, t2
WHERE t3.a = t1.a AND t1.a = t2.a;

Now the planner/optimizer has _ALL_ the tables that need to
be scanned and _ALL_ the qualifications in _ONE_ querytree.
It is the job of the optimizer to decide which is the best
join path for this access. To make a good decision, it needs
all this information plus the VACUUM statistics.

If we put any view into a subquery RTE, we force the planner
to materialize the view and do a nestloop over t3 and
materialized v1 where possibly using t1 or t2 as the
outermost scanrelation would be better.

Stonebraker & Co where absolutely right when they spoke about
productional rule systems. And what PostgreSQL does now is
how I understood them.

"Production rule systems are conceptually simple, but
there are many subtle points involved in actually using
them."
-- Stonebraker

I think the different grouping requirements for subsets of
data when using aggregate columns in views is just one of the
the problems he addressed with the above statement.

We should build a subquery RTE only if Query->hasAggs is
true.

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 Tom Lane 1998-11-24 15:55:43 Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Previous Message Karl Auer 1998-11-24 15:49:43 pg_dump - segfault with -z option

Browse pgsql-sql by date

  From Date Subject
Next Message Jan Wieck 1998-11-24 16:07:06 Re: [SQL] MINUS and slow 'not in'
Previous Message Herouth Maoz 1998-11-24 15:32:59 Re: [SQL] MINUS and slow 'not in'