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) #
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 |
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' |