From: Simon Riggs <simon@2ndquadrant.com>
To: Robert Treat <xzilla@users.sourceforge.net>
Cc: pgsql-performance@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: Csaba Nagy <nagy@ecircle-ag.com>
Cc: Bill Moran <wmoran@collaborativefusion.com>
Subject: Re: TB-sized databases
Date: Thu, 06 Dec 2007 09:38:16 +0000
Message-ID: <1196933896.4255.340.camel@ebony.site> (raw)
In-Reply-To: <200712051507.22745.xzilla@users.sourceforge.net>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
<13851.1196351131@sss.pgh.pa.us>
<1196352866.4246.1304.camel@ebony.site>
<200712051507.22745.xzilla@users.sourceforge.net>
Robert,
On Wed, 2007-12-05 at 15:07 -0500, Robert Treat wrote:
> If the whole performance of your system depends upon indexed access, then
> maybe you need a database that gives you a way to force index access at the
> query level?
That sounds like a request for hints, which is OT here, ISTM.
The issue is that if somebody issues a "large query" then it will be a
problem whichever plan the query takes. Forcing index scans can make a
plan more expensive than a seq scan in many cases.
> > e.g. An 80GB table has 8 million blocks in it.
> > - So putting a statement_cost limit = 1 million would allow some fairly
> > large queries but prevent anything that did a SeqScan (or worse).
> > - Setting it 10 million is going to prevent things like sorting the
> > whole table without a LIMIT
> > - Setting it at 100 million is going to prevent unconstrained product
> > joins etc..
>
> I think you're completly overlooking the effect of disk latency has on query
> times. We run queries all the time that can vary from 4 hours to 12 hours in
> time based solely on the amount of concurrent load on the system, even though
> they always plan with the same cost.
Not at all. If we had statement_cost_limit then it would be applied
after planning and before execution begins. The limit would be based
upon the planner's estimate, not the likely actual execution time.
So yes a query may vary in execution time by a large factor as you
suggest, and it would be difficult to set the proposed parameter
accurately. However, the same is also true of statement_timeout, which
we currently support, so I don't see this point as an blocker.
Which leaves us at the burning question: Would you use such a facility,
or would the difficulty in setting it exactly prevent you from using it
for real?
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
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: simon@2ndquadrant.com, xzilla@users.sourceforge.net, tgl@sss.pgh.pa.us, stark@enterprisedb.com, nagy@ecircle-ag.com, wmoran@collaborativefusion.com
Subject: Re: TB-sized databases
In-Reply-To: <1196933896.4255.340.camel@ebony.site>
* 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