From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Mattos <omattos(at)gmail(dot)com> |
Cc: | Arne Roland <A(dot)Roland(at)index(dot)de>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query planner gaining the ability to replanning after start of query execution. |
Date: | 2017-11-13 22:49:33 |
Message-ID: | 4276.1510613373@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Oliver Mattos <omattos(at)gmail(dot)com> writes:
>> Can you be more elaborate how you'd want to go about it?
> ... If another candidate plan is now lower cost, the current plan would be
> terminated[1] by setting a flag instructing each execnode to return as
> if it had reached the end of the input, although still caching the
> node selectivity values, and the new plan started from scratch.
Quite aside from the implementation difficulties you'll have, that
approach is a show-stopper right there. You can't just restart from
scratch, because we may already have shipped rows to the client, or
for DML cases already inserted/updated/deleted rows (and even if you
could roll those back, we've possibly fired triggers with unpredictable
side effects). Queries containing volatile functions are another no-fly
zone for this approach.
I can't see any way around that without unacceptable performance costs
(i.e. buffering all the rows until we're done) or wire-protocol breakage.
I think that a more practical way to address the class of problems
you're talking about is to teach the planner to have some notion of
worst-case as well as expected-case costs, and then incorporate some
perhaps-configurable amount of risk aversion in its choices.
regards, tom lane
PS: please do not top-post, and do not quote the entire darn thread
in each message.
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Mattos | 2017-11-13 23:20:44 | Re: Query planner gaining the ability to replanning after start of query execution. |
Previous Message | Arne Roland | 2017-11-13 22:48:49 | Re: Query planner gaining the ability to replanning after start of query execution. |