Re: Rewrite, normal execution vs. EXPLAIN ANALYZE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rewrite, normal execution vs. EXPLAIN ANALYZE
Дата
Msg-id 23778.1280947553@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rewrite, normal execution vs. EXPLAIN ANALYZE  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Ответы Re: Rewrite, normal execution vs. EXPLAIN ANALYZE  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
> According to the latter commit, not updating the snapshot could be 
> preferable for EXPLAIN ANALYZE, but I don't see why this is.  Maybe we 
> should wait until we hear from Tom?

Sorry for not catching up on my email sooner.  On the whole I'm in
agreement with the argument that wCTEs should *not* take whole new
snapshots between queries, but only advance the CID.  The points
that sway me that way are:

1. To do otherwise will decrease the predictability of wCTE results.

2. The argument for taking a new snapshot seems to be mostly
"because that's what rules do"; but it's agreed that rules have a
lot of surprising and undesirable behavior, and it's not clear that
this isn't part of that.

3. In particular I don't agree with the argument that functions taking
new snapshots between queries should be a precedent for this.  In
a function, the user thinks of the successive lines as separate queries,
and it's reasonable for them to act similarly to what would happen if
they were issued as separate top-level commands.  I do not see that that
argument applies to wCTEs, which by definition are parts of a single
command.

In any case the behavior is going to have to be documented, but I vote
for advance-CID-only so far as wCTEs are concerned.

The other thing that was being argued was whether rules should be
changed to act that way too, and if not whether EXPLAIN ANALYZE should
be fixed to make sure it emulates rule execution better.  Personally
I'd be in favor of changing rule execution and leaving EXPLAIN ANALYZE
alone, though I'm not sure if that position can command a consensus.
I seriously doubt that there are many applications out there that are
actually depending on this aspect of rule execution; if anything, there
are probably more that will see it as a bug.
        regards, tom lane


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

Предыдущее
От: Yeb Havinga
Дата:
Сообщение: Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)