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
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? |