Mark Roberts wrote:
- It'd be nice if the query planner was more "stable" - sometimes the queries run fast, and then sometimes they randomly take 2 hours for a delete that normally runs in a couple of minutes.
I was going to stay silent, because my pet peeves were already covered or had been fixed (btw, thanks to whomever fixed sql standard "quote escaping a quote" all those years ago :-) ). But Mark's suggestion is excellent. Plan stability / Stored planner outlines / whatever you want to call it, is hugely valuable when data volumes change so frequently that the planner never knows the "good" stats from the "bad", and also when upgrading to lessen the "OMG, I have to add set enable_nestloop=false to 48 billion queries just to overcome new planner quirks" situations. $OTHER_BIG_RDBMS have had this to varying degrees for a while (stored outlines/plan stability in Oracle; bind in DB2; whatever crap name MS gave their half-arsed version), and when it's mature, the certainty around execution is a life-saver. And just to chime in on the already mentioned things: - in-place upgrades - replication engine in the core - true stored procedures - job scheduler in the core In all, a short list, which is an oblique way of saying thanks to everyone for the enormous strides that have been made in the last few years :-) Ciao Fuzzy :-) ------------------------------------------------ Dazed and confused about technology for 20 years http://fuzzydata.wordpress.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
