From: | "Kevin O'Gorman" <kogorman(at)pacbell(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PGSQL Hackers List <pgsql-hackers(at)hub(dot)org> |
Subject: | Re: Rule system goes weird with SELECT queries |
Date: | 2000-10-19 23:50:51 |
Message-ID: | 39EF88DB.D8225D22@pacbell.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for the reply. I'll look into setting up CVS -- I've
just
been using the distributed 7.0.2 actually.
Moreover, the situation is even a bit more confused for me.
When
I actually *execute* the 'insert into dummy', I get the
output
of only one select: the second one listed. Is there
something
about executing a list I don't know about, or is this also
old news??
++ kevin
Tom Lane wrote:
>
> "Kevin O'Gorman" <kogorman(at)pacbell(dot)net> writes:
> > If I define two rules for the same action, each with
> > a single select command, I wind up with two selects as
> > expected, but they are both cross-product selects on the
> > two tables. This is unexpected.
>
> Rangetable leakage, sounds like --- the two queries are sharing the same
> list of rangetable entries, and that's what the planner joins over. Not
> sure if it's *good* that they share the same rtable list, or if that's a
> bug. In any event, it's old news because current sources don't use the
> rtable list to control joining; now there is a separate join tree, which
> is definitely not shared. I get
>
> regression=# create rule rule4a as on insert to dummy do instead select * from
> d2;
> CREATE
> regression=# create rule rule4b as on insert to dummy do instead select * from
> d3;
> CREATE
> regression=# explain insert into dummy values(1);
> NOTICE: QUERY PLAN:
>
> Seq Scan on d2 (cost=0.00..20.00 rows=1000 width=4)
>
> NOTICE: QUERY PLAN:
>
> Seq Scan on d3 (cost=0.00..20.00 rows=1000 width=4)
>
> EXPLAIN
>
> which looks fine. Can't check your other example, since the grammar
> file hasn't been changed to allow it...
>
> I'm not sure whether to recommend that you work from current CVS sources
> or not. A couple weeks ago that's what I would have said, but Vadim is
> halfway through integrating WAL changes and I'm not sure how stable the
> tip really is. You could try the tip, and if it blows up fall back to
> a dated retrieval from about 7-Oct. Or you could investigate the way
> that the 7.0.* rewriter handles the rtable list for multiple queries,
> but that's probably not a real profitable use of your time.
>
> regards, tom lane
--
Kevin O'Gorman (805) 650-6274 mailto:kogorman(at)pacbell(dot)net
Permanent e-mail forwarder:
mailto:Kevin.O'Gorman(dot)64(at)Alum(dot)Dartmouth(dot)org
At school: mailto:kogorman(at)cs(dot)ucsb(dot)edu
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html
"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-10-19 23:52:14 | Re: time stops within transaction |
Previous Message | Tom Lane | 2000-10-19 23:49:09 | Re: Conditional query plans. |