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.
http://en.wiktionary.or
Robert Haas 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 mailing list (pgsql-ha
Robert Haas wrote:
> On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Robert Haas writes:
> >> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
> >> >> I seriously doubt that there are many applications out there that are
> >> >> actually depending on this aspect o
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
>> >> I seriously doubt that there are many applications out there that are
>> >> actually depending on this aspect of rule execution; if anything,
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane 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 bug.
>
>
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 shoul
On Mon, Aug 30, 2010 at 5:30 PM, Marko Tiikkaja
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 add this to the currentl
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
***
*** 832,838
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 l
Robert Haas writes:
> On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane 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 bug.
> Changing EXPLAIN ANALYZE see
On 8/4/2010 10:26 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane 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
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane 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 changing rule exe
Marko Tiikkaja 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 argume
On 7/24/2010 1:43 AM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera
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 found the commit that chang
Marko Tiikkaja 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 forgot that they did it with
On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera
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 think it's fair game
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 ch
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 exec
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 po
On 7/24/10 12:42 AM +0300, Kevin Grittner wrote:
Alvaro Herrera 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
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
Alvaro Herrera 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@postgresql.org)
To make changes to yo
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
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
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 ch
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
> On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
> 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
On Fri, Jul 23, 2010 at 3:31 PM, David Fetter 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
>> wrote:
>> > This may be a bit hard to follow, but essentially what happens is
>> > that in EXPLAIN ANALYZE, the INSERT in the r
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
> On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
> 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
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
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.
Well that's gotta be a bug, bu
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 7/23/2010 10:00 PM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja
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 EXPLAIN ANALYZE does *not* tak
On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja
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 that this w
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?
Currentl
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 sna
33 matches
Mail list logo
