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
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 performance
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 stupid question, but
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 option to
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...
Tom's previous
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
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 Linux? Or
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, XML message
10 matches
Mail list logo
