Re: Rewrite, normal execution vs. EXPLAIN ANALYZE

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Rewrite, normal execution vs. EXPLAIN ANALYZE
Дата
Msg-id 1279920723-sup-8320@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Rewrite, normal execution vs. EXPLAIN ANALYZE  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Ответы Re: Rewrite, normal execution vs. EXPLAIN ANALYZE  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Rewrite, normal execution vs. EXPLAIN ANALYZE  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Список pgsql-hackers
Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010:
> On 7/23/2010 8:52 PM, David Fetter wrote:
> > On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote:
> >> Did I misunderstand the code?  And if I didn't, why do we do this
> >> differently?
> >
> > You mentioned in IRC that this was in aid of getting wCTEs going.  How
> > are these things connected?
> 
> Currently, I'm trying to make wCTEs behave a bit like RULEs do.  But if 
> every rewrite product takes a new snapshot, wCTEs will behave very 
> unpredictably.

I don't think it's fair game to change the behavior of multiple-output
rules at this point.  However, I also think that it's unwise to base
wCTEs on the behavior of rules -- rules are widely considered broken and
unusable for nontrivial cases.

Also, I think that having a moving snapshot for the different parts of a
wCTE is going to mean they're unpredictable.  For predictable usage
you'll be forcing the user to always wrap them in SERIALIZABLE
transactions.

In short I think a wCTE should only advance the CID, not get a whole new
snapshot.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: patch: to_string, to_array functions
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Rewrite, normal execution vs. EXPLAIN ANALYZE