From: Gregory Stark <stark@enterprisedb.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Csaba Nagy <nagy@ecircle-ag.com>
Cc: Bill Moran <wmoran@collaborativefusion.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: TB-sized databases
Date: Thu, 29 Nov 2007 11:59:51 +0000
Message-ID: <878x4hmfd4.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <1196270576.4246.1246.camel@ebony.site>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
<474B1407.3090607@laotraesquina.com.ar>
<474B1B8C.1030505@gmail.com>
<4544e0330711271218h56ce4cc3p280a9fefff24583d@mail.gmail.com>
<1196197045.4246.1154.camel@ebony.site>
<474CA2FA.2020201@laotraesquina.com.ar>
<Pine.LNX.4.58.0711281248290.3731@aragorn.flymine.org>
<20071128082716.91bbad9c.wmoran@collaborativefusion.com>
<1196257702.31315.6.camel@PCD12478>
<1196270576.4246.1246.camel@ebony.site>
"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Wed, 2007-11-28 at 14:48 +0100, Csaba Nagy wrote:
>
>> In fact an even more useful option would be to ask the planner to throw
>> error if the expected cost exceeds a certain threshold...
>
> Well, I've suggested it before:
>
> statement_cost_limit on pgsql-hackers, 1 March 2006
>
> Would people like me to re-write and resubmit this patch for 8.4?
>
> Tom's previous concerns were along the lines of "How would know what to
> set it to?", given that the planner costs are mostly arbitrary numbers.
Hm, that's only kind of true.
Since 8.mumble seq_page_cost is itself configurable meaning you can adjust the
base unit and calibrate all the parameters to be time in whatever unit you
choose.
But even assuming you haven't so adjusted seq_page_cost and all the other
parameters to match the numbers aren't entirely arbitrary. They represent time
in units of "however long a single sequential page read takes".
Obviously few people know how long such a page read takes but surely you would
just run a few sequential reads of large tables and set the limit to some
multiple of whatever you find.
This isn't going to precise to the level of being able to avoid executing any
query which will take over 1000ms. But it is going to be able to catch
unconstrained cross joins or large sequential scans or such.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stark@enterprisedb.com, simon@2ndquadrant.com, nagy@ecircle-ag.com, wmoran@collaborativefusion.com
Subject: Re: TB-sized databases
In-Reply-To: <878x4hmfd4.fsf@oxford.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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