Please post EXPLAIN ANALYZE output for the two queries.
As I wrote in my first post, I pasted this together with the two queries
at pastebin.com:
http://pastebin.com/m3c0d1896
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
Hi Peter,
If you run into a scaling issue with PG (you will at those scales 1TB+), you
can deploy Greenplum DB which is PG 8.2.5 compatible. A large internet
company (look for press soon) is in production with a 150TB database on a
system capable of doing 400TB and we have others in production at
In response to Matthew <[EMAIL PROTECTED]>:
> On Fri, 30 Nov 2007, cluster wrote:
> > Can anyone explain the following odd behavior?
> > I have a query that completes in about 90 ms. If I append LIMIT to the
> > very end, eg. "LIMIT 500" the evaluation time increases to about 800 ms.
> > How can p
On Thu, 29 Nov 2007, Matthew T. O'Connor wrote:
> Matthew wrote:
> > For instance, the normal B-tree index on (a, b) is able to answer queries
> > like "a = 5 AND b > 1" or "a > 5". An R-tree would be able to index these,
> > plus queries like "a > 5 AND b < 1".
>
> Sorry in advance if this is a st
On Fri, 30 Nov 2007, cluster wrote:
> Can anyone explain the following odd behavior?
> I have a query that completes in about 90 ms. If I append LIMIT to the
> very end, eg. "LIMIT 500" the evaluation time increases to about 800 ms.
> How can performance get *worse* by giving the database the optio
Can anyone explain the following odd behavior?
I have a query that completes in about 90 ms. If I append LIMIT to the
very end, eg. "LIMIT 500" the evaluation time increases to about 800 ms.
How can performance get *worse* by giving the database the option to
stop the evaluation earlier (when it
> Isn't that what statement_timeout is for? Since this is entirely based
> on estimates, using arbitrary fuzzy numbers for this seems fine to me;
> precision isn't really the goal.
There's an important difference to statement_timeout: this proposal
would avoid completely taking any resources if it
On 11/29/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> 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...
>
On Wednesday 28 November 2007 11:20, Usama Munir Dar wrote:
> EnterpriseDB (www.enterprisedb.com), ofcourse
>
lame :-P
> Campbell, Lance wrote:
> > PostgreSQL: 8.2.4
> >
> >
> >
> > Does anyone have any companies they would recommend using for
> > performance tuning training of PostgreSQL for Lin
On Fri, 2007-11-30 at 17:41 +1100, Russell Smith wrote:
> Simon Riggs wrote:
> > On Tue, 2007-11-27 at 18:06 -0500, Pablo Alcaraz wrote:
> >
> >> Simon Riggs wrote:
> >>
> >>> All of those responses have cooked up quite a few topics into one. Large
> >>> databases might mean text warehouses
10 matches
Mail list logo
