performance@postgresql.org
Subject: Re: [PERFORM] Query planner gaining the ability to replanning after
start of query execution.
> Can you be more elaborate how you'd want to go about it?
My initial approach would be to try to identify places in the plan
where selectivity is serious
alf Of Oliver Mattos
Sent: Monday, November 13, 2017 5:45 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Query planner gaining the ability to replanning after start
of query execution.
I am interested in giving the query planner the ability to replan (or re-rank
plans) after query e
> You can't just restart from scratch, because we may already have shipped
> rows to the client
For v1, replanning wouldn't be an option if rows have already been
shipped, or for DML statements.
> parallel plans and most importantly cursors?
Parallel plans look do-able with the same approach, b
Oliver Mattos 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
doubt
> that's worth any work (and even less the maintenance).
>
> Best regards
> Arne Roland
>
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org
> [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Oliver Mattos
> Sent: Monday, Novemb
I am interested in giving the query planner the ability to replan (or
re-rank plans) after query execution has begun, based on the
progression of the query so far.
Example use case:
* A LIMIT 1 query is planned using an expensive scan which the
planner expects to return a large number of results
