Re: Rule system goes weird with SELECT queries

Поиск
Список
Период
Сортировка
От Kevin O'Gorman
Тема Re: Rule system goes weird with SELECT queries
Дата
Msg-id 39EF88DB.D8225D22@pacbell.net
обсуждение исходный текст
Ответ на Rule system goes weird with SELECT queries  ("Kevin O'Gorman" <kogorman@pacbell.net>)
Ответы Re: Rule system goes weird with SELECT queries
Список 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 по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: time stops within transaction
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rule system goes weird with SELECT queries