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

Re: TB-sized databases

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: TB-sized databases
Date: 2007-11-29 11:59:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Simon Riggs" <simon(at)2ndquadrant(dot)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

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
  Ask me about EnterpriseDB's RemoteDBA services!

In response to


pgsql-performance by date

Next:From: Brad NicholsonDate: 2007-11-29 15:10:54
Subject: 7.4 Checkpoint Question
Previous:From: clusterDate: 2007-11-29 11:07:37
Subject: Re: Query only slow on first run

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