: Freitag, 18. September 2009 17:43
An: Hell, Robert
Cc: t...@fuzzy.cz; pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] Different query plans for the same query
Hell, Robert robert.h...@fabasoft.com writes:
bad plan (sometimes with statistcs target 100, seconds after the good plan
Hi all,
on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans
for one of our (weird) queries are generated. One of the query plans
seems to be good (and is used most of the time). The other one is bad -
the query takes about 2 minutes and the database process, which is
executing
increasing default statistics
target should make statistics (and query plans) better.
Regards,
Robert
-Ursprüngliche Nachricht-
Von: t...@fuzzy.cz [mailto:t...@fuzzy.cz]
Gesendet: Freitag, 18. September 2009 11:20
An: Hell, Robert
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM
Of Ivan Voras
Sent: Dienstag, 08. April 2008 11:03
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Looking for bottleneck during load test
Hell, Robert wrote:
I tried different other tools for random IO (including a self
written one which does random lseek and read).
This tool
We have a PostgreSQL 8.2.7 database (~230 GB) running on a machine with 8 Intel
Xeon Cores and 32 GB RAM (64-bit Linux 2.6.18). Data is stored on an EMC²
CLARiiON on RAID 1/0 (8 x 146 GB 15k rpm).
When we do random I/O with a small test tool (reading random 8k blocks from big
files in 200
for bottleneck during load test
Hell, Robert wrote:
We have a PostgreSQL 8.2.7 database (~230 GB) running on a machine with 8
Intel Xeon Cores and 32 GB RAM (64-bit Linux 2.6.18). Data is stored on an
EMC² CLARiiON on RAID 1/0 (8 x 146 GB 15k rpm).
When we do random I/O with a small test tool
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursors and different settings for
default_statistics_target
Hell, Robert [EMAIL PROTECTED] writes:
But why are the first 15 fetches (15360 rows) processed in 0.5 seconds
and the last fetch (998 rows) takes 7 seconds
Hi,
the following statement retrieves 16358 rows in a cursor by fetching
1024 rows in bulks on a 8.2.4 server:
DECLARE curs_285058224 CURSOR FOR SELECT objid, attrid, aggrid, lineid,
objval FROM atobjval WHERE objid IN
(281479288456304,281479288456359,281479288456360,281479288456384,2814792
calculation for cursors and straight
queries?
Kind regards,
Robert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 01. April 2008 17:30
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursors and different settings
,
Robert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 01. April 2008 18:17
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursors and different settings for
default_statistics_target
Hell, Robert [EMAIL PROTECTED] writes
)
Filter: (objid = ANY ('{281479288456304,many of
them,285774255837674}'::bigint[]))
Regards,
Robert
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 01. April 2008 18:42
An: Hell, Robert
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM
11 matches
Mail list logo
