Skip site navigation (1) Skip section navigation (2)

Re: Pet Peeves?

From: Grant Allen <gxallen(at)gmail(dot)com>
To: Mark Roberts <mailing_lists(at)pandapocket(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Pet Peeves?
Date: 2009-02-04 23:01:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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 :-)


Dazed and confused about technology for 20 years

In response to

pgsql-general by date

Next:From: Jeff DavisDate: 2009-02-04 23:33:06
Subject: Re: Sort method: external merge
Previous:From: Raymond O'DonnellDate: 2009-02-04 22:38:00
Subject: Re: Elapsed time between timestamp variables in Function

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group