Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I seriously doubt that there are many applications out there that are
actually depending on
Robert Haas wrote:
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I seriously doubt that there are many applications out there that are
Robert Haas robertmh...@gmail.com writes:
The status of that patch is that Tom promised to look at it two months
ago and hasn't. It would be nice if someone else could pick it up.
I'm pedaling as fast as I can, honestly.
regards, tom lane
--
Sent via pgsql-hackers
On Feb 17, 2011, at 11:28 AM, Tom Lane wrote:
The status of that patch is that Tom promised to look at it two months
ago and hasn't. It would be nice if someone else could pick it up.
I'm pedaling as fast as I can, honestly
Tom leaves everything on the road.
On 2010-08-31 12:07 AM +0300, I wrote:
The patch needs a bit more comments and some cleaning up ..
Here's a cleaned up version with a bit more comments.
This patch still silently breaks pg_parse_and_rewrite(). We only use it
in our source code for SQL-language functions, so I think we
On Mon, Aug 30, 2010 at 5:30 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-08-31 12:07 AM +0300, I wrote:
I looked at fixing this..
The previous patch had a bug in fmgr_sql() our regression tests didn't
catch. Fixed version attached.
It would probably be a good idea to
Hi,
I looked at fixing this inconsistency by making all query list snapshot
handling work like EXPLAIN ANALYZE's code does. The only reason I went
this way was that implementing wCTEs on top of this behaviour is a lot
easier.
There were three places that needed fixing. The SPI and portal
On 2010-08-31 12:07 AM +0300, I wrote:
I looked at fixing this..
The previous patch had a bug in fmgr_sql() our regression tests didn't
catch. Fixed version attached.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
***
Marko Tiikkaja marko.tiikk...@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
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 8/4/2010 10:26 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lanet...@sss.pgh.pa.us wrote:
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 7/24/2010 1:43 AM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It seems like it's EXPLAIN ANALYZE that needs fixing.
I would suggest that if we're going to change this, we back-patch it
to 9.0 before beta4.
I did some digging and
On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote:
Hi,
From the code I understood that when executing a query normally,
in READ COMMITTED mode, we take a new snapshot for every query that
comes out of rewrite. But in an EXPLAIN ANALYZE, we only update the
CID of the snapshot
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?
On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
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
On 7/23/2010 10:00 PM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
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
On 7/23/2010 10:06 PM, I wrote:
ProcessQuery() and ExplainOnePlan(). ProcessQuery calls
PushActiveSnapshot(GetTransactionSnapshot()) for every statement while
ExplainOnePlan calls PushUpdatedSnapshot(GetActiveSnapshot()).
Here's a test case demonstrating the difference:
=# create table foo(a
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is that in
EXPLAIN ANALYZE, the INSERT in the rule does not see the changes made by T2
to baz while in the regular execution scenario it does.
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is
that in EXPLAIN ANALYZE, the INSERT in the rule does not see the
changes made
On Fri, Jul 23, 2010 at 3:31 PM, David Fetter da...@fetter.org wrote:
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is
that in
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is that in
EXPLAIN ANALYZE, the INSERT in the rule does not see the changes made by
On 7/23/2010 10:46 PM, Andres Freund wrote:
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is that in
EXPLAIN ANALYZE, the INSERT
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
Alvaro Herrera alvhe...@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
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
On 7/24/10 12:42 AM +0300, Kevin Grittner wrote:
Alvaro Herreraalvhe...@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
Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010:
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:
I don't think it's fair game to change the behavior of multiple-output
rules at this point.
On 7/24/10 1:20 AM +0300, Alvaro Herrera wrote:
Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010:
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
On 7/24/10 1:20 AM +0300, Alvaro Herrera wrote:
It seems like it's EXPLAIN ANALYZE that needs fixing.
Yeah, looks like it. I see SQL functions also take a new snapshot for
every query.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010:
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:
I don't
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
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.
Never mind -- I remembered that those could operate against tuples
not in the original snapshot, but
Hi,
From the code I understood that when executing a query normally, in
READ COMMITTED mode, we take a new snapshot for every query that comes
out of rewrite. But in an EXPLAIN ANALYZE, we only update the CID of
the snapshot taken when the EXPLAIN started.
Did I misunderstand the code?
34 matches
Mail list logo
