Rewrite, normal execution vs. EXPLAIN ANALYZE
in [PgSql]
|
From: Marko Tiikkaja on 23 Jul 2010 14:13 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. But because EXPLAIN ANALYZE does *not* take a new snapshot for every rewrite product, I'm starting to think that maybe this isn't the behaviour we wanted to begin with? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 23 Jul 2010 17:37 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 23 Jul 2010 17:42 Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > In short I think a wCTE should only advance the CID, not get a > whole new snapshot. Even after unblocking from a write conflict at the READ COMMITTED isolation level? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 23 Jul 2010 17:44 On 7/24/10 12:37 AM +0300, Alvaro Herrera wrote: > 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. I don't want to change the behaviour either, but we have two different behaviours right now. We need to change at least the other. wCTEs are not going to be based on any of the broken behaviour of rules, that's for sure. What I meant is expanding a single query into multiple queries and running the executor separately for all of them. > 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. That is *not* what has been discussed for wCTEs. A wCTE will only modify the CID of the snapshot in any isolation mode. > In short I think a wCTE should only advance the CID, not get a whole new > snapshot. Agreed. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 23 Jul 2010 17:48 On 7/24/10 12:42 AM +0300, Kevin Grittner wrote: > Alvaro Herrera<alvherre(a)commandprompt.com> wrote: > >> In short I think a wCTE should only advance the CID, not get a >> whole new snapshot. > > Even after unblocking from a write conflict at the READ COMMITTED > isolation level? I'm not sure what you mean by this; UPDATE and DELETE can take a look at the new tuple but that's completely separate from the snapshot. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) Next: [HACKERS] reminder... beta4 is coming |