pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedA pessimistic planner
2+ messages / 2 participants
[nested] [flat]
* A pessimistic planner
@ 2014-11-21 05:07 Stuart Bishop <stuart@stuartbishop.net>
0 siblings, 1 reply; 2+ messages in thread
From: Stuart Bishop @ 2014-11-21 05:07 UTC (permalink / raw)
To: pgsql-performance
Another day, another timing out query rewritten to force a more stable
query plan.
While I know that the planner almost always chooses a good plan, I
tend to think it is trying too hard. While 99% of the queries might be
10% faster, 1% might be timing out which makes my users cross and my
life difficult. I'd much rather have systems that are less efficient
overall, but stable with a very low rate of timeouts.
I was wondering if the planner should be much more pessimistic,
trusting in Murphy's Law and assuming the worst case is the likely
case? Would this give me a much more consistent system? Would it
consistently grind to a halt doing full table scans? Do we actually
know the worst cases, and would it be a relatively easy task to update
the planner so we can optionally enable this behavior per transaction
or across a system? Boolean choice between pessimistic or optimistic,
or is pessimism a dial?
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: A pessimistic planner
@ 2014-11-21 05:12 Tom Lane <tgl@sss.pgh.pa.us>
parent: Stuart Bishop <stuart@stuartbishop.net>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2014-11-21 05:12 UTC (permalink / raw)
To: Stuart Bishop <stuart@stuartbishop.net>; +Cc: pgsql-performance
Stuart Bishop <stuart@stuartbishop.net> writes:
> I was wondering if the planner should be much more pessimistic,
> trusting in Murphy's Law and assuming the worst case is the likely
> case? Would this give me a much more consistent system?
Well, it would give uniformly awful plans for cases where fast-start
plans are actually useful ... and there are plenty.
We do need to think of ways to account for risk, but I don't think
that jamming the tiller all the way over is likely to be a net
improvement.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2014-11-21 05:12 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-11-21 05:07 A pessimistic planner Stuart Bishop <stuart@stuartbishop.net>
2014-11-21 05:12 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox