Re: Rule system goes weird with SELECT queries

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

In response to

Responses

Browse pgsql-hackers by date

  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.