Re: Writeable CTE Not Working?

From: Kong Man <kong_mansatiansin(at)hotmail(dot)com>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <vyegorov(at)gmail(dot)com>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Writeable CTE Not Working?
Date: 2013-01-30 02:45:56
Message-ID: DUB116-W353526CD12D2106765BAE08B1E0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql


> I think this explanation is wrong --- if you run the query with EXPLAIN
> ANALYZE, you can see from the rowcounts that the writable CTE *does* get
> run to completion, as indeed is stated to be the behavior in the fine
> manual.
>
> However, for a case like this where the main query isn't reading from
> the CTE, the CTE will get cycled to completion after the main query is
> done. I think what is happening is that the main query is updating all
> the rows in the table, and then when the CTE comes along it thinks the
> rows are already updated in the current command, so it doesn't replace
> 'em a second time. This is a consequence of the fact that the same
> command-counter ID is used throughout the query. My recollection is
> that that choice was intentional and that doing it differently would
> break use-cases that are less outlandish than this one. I don't recall
> specific examples though.

Cool. Now I understand it much better.

> Why are you trying to update the same table in two different parts of
> this query, anyway? The best you can really hope for with that is
> unspecified behavior --- we will surely not promise that one of them
> completes before the other starts, so in general there's no way to be
> sure which one would process a particular row first.

It was just my misuse of writable CTE thinking it would be more efficient than separate statements.

Best regards,
-Kong

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Bert 2013-01-31 09:43:49 Partition tables to improve select speed?
Previous Message Tom Lane 2013-01-30 01:16:40 Re: Writeable CTE Not Working?