I wrote:
I'm inclined to think that it would be best to move the responsibility
for calling AfterTriggerBeginQuery/AfterTriggerEndQuery into the
executor. That would get us down to
CreateQueryDesc(...);
ExecutorStart(...); // now includes AfterTriggerBeginQuery
On 26.02.2011 07:55, Tom Lane wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way.
Could you keep the sequence unchanged for non-EXPLAIN callers with some
On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way. The only way I see to fix this
without changing
On 26 February 2011 05:55, Tom Lane t...@sss.pgh.pa.us wrote:
Further experimentation has reminded me of why I didn't want to put such
processing in ExecutorEnd :-(. There are some nasty interactions with
EXPLAIN:
1. EXPLAIN ANALYZE fails to include the execution cycles associated with
Greg Stark gsst...@mit.edu writes:
On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way. The only way I
On Sat, Feb 26, 2011 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment we dodge that issue by disallowing wCTEs in cursors.
If we did allow them, then I would say that the wCTEs have to be run to
completion when the cursor is closed.
Does that really dodge anything? Isn't it
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 26.02.2011 07:55, Tom Lane wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way.
Could you keep the
On 2011-02-26 7:18 PM, Tom Lane wrote:
IMO the major disadvantage of a refactoring like this is the possibility
of sins of omission in third-party code, in particular somebody not
noticing the added requirement to call ExecutorFinish. We could help
them out by adding an Assert in ExecutorEnd to
On Fri, Feb 25, 2011 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing
Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've decided to run the modifying sub-queries all with
the same command counter ID, they are logically executing in
parallel.
Just run the main plan and let it pull tuples from the CTEs as
needed.
On the face of it, that sounds like it has
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've decided to run the modifying sub-queries all with
the same command counter ID, they are logically executing in
parallel.
Just run the main plan and let it pull tuples from the CTEs as
On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to
InitPlan and ExecutePlan that find all the modifying sub-queries and
force them to be cycled to completion before the main plan runs.
Just run the main plan and let it pull tuples from the
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are interleaved not sequential. We're never going to be
able to do any
On Fri, Feb 25, 2011 at 11:31 AM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are
Greg Stark gsst...@mit.edu writes:
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are interleaved not sequential.
Does the
On Fri, Feb 25, 2011 at 09:58:36AM -0500, Tom Lane wrote:
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing in
David Fetter da...@fetter.org writes:
What's the effect, if any, on CTEs that depend on each other
explicitly?
An error. That would require mutual recursion, which we don't
support for the SELECT case let alone data-modifying statements.
regards, tom lane
--
Sent via
On Fri, Feb 25, 2011 at 10:12:02PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
What's the effect, if any, on CTEs that depend on each other
explicitly?
An error. That would require mutual recursion, which we don't
support for the SELECT case let alone data-modifying
David Fetter da...@fetter.org writes:
Sorry that was unclear. Let's imagine there's a DELETE ... RETURNING
in one WITH, and an UPDATE in another that depends on that one. Is
that still allowed?
Yeah it is, although I just noticed that there's a bug in the new
implementation:
with t1 as
I wrote:
The first solution that comes to mind is to pay attention to the
interdependencies of the CTEs, and perform the cleanup in an appropriate
order (here, the ModifyTable for y needs to be cycled first).
Doh ... actually, we already *are* ordering the CTEs in dependency
order, so it's a
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to
InitPlan and ExecutePlan that find all the modifying sub-queries and
force them to be cycled to completion before the main plan runs.
21 matches
Mail list logo
