Re: Rule system goes weird with SELECT queries - Mailing list pgsql-hackers
From | Kevin O'Gorman |
---|---|
Subject | Re: Rule system goes weird with SELECT queries |
Date | |
Msg-id | 39EF88DB.D8225D22@pacbell.net Whole thread Raw |
In response to | Rule system goes weird with SELECT queries ("Kevin O'Gorman" <kogorman@pacbell.net>) |
Responses |
Re: Rule system goes weird with SELECT queries
|
List | 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@pacbell.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@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.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
pgsql-hackers by date: