Hi,
i recently run pgbench against different servers and got some results I
dont quite understand.
A) EV1: Dual Xenon, 2GHz, 1GB Memory, SCSI 10Krpm, RHE3
B) Dual Pentium3 1.4ghz (Blade), SCSI Disk 10Krmp, 1GB Memory, Redhat 8
C) P4 3.2GHz, IDE 7.2Krpm, 1GBMem, Fedora Core2
All did run only postg
On Dec 23, 2004, at 9:27 AM, Alex wrote:
Running hdparm reported
A) 920mb/s (SCSI 10k)
B) 270mb/s (SCSI 10k)
C) 1750mb/s (IDE 7.2k)
IDE disks lie about write completion (This can be disabled on some
drives) whereas SCSI drives wait for the data to actually be written
before they report su
Alex wrote:
Hi,
i recently run pgbench against different servers and got some results I
dont quite understand.
A) EV1: Dual Xenon, 2GHz, 1GB Memory, SCSI 10Krpm, RHE3
B) Dual Pentium3 1.4ghz (Blade), SCSI Disk 10Krmp, 1GB Memory, Redhat 8
C) P4 3.2GHz, IDE 7.2Krpm, 1GBMem, Fedora Core2
>
Runnig P
Jeff wrote:
On Dec 23, 2004, at 9:27 AM, Alex wrote:
Running hdparm reported
A) 920mb/s (SCSI 10k)
B) 270mb/s (SCSI 10k)
C) 1750mb/s (IDE 7.2k)
IDE disks lie about write completion (This can be disabled on some
drives) whereas SCSI drives wait for the data to actually be written
before th
IDE disks lie about write completion (This can be disabled on some
drives) whereas SCSI drives wait for the data to actually be written
before they report success. It is quite
easy to corrupt a PG (Or most any db really) on an IDE drive. Check
the archives for more info.
Do we have any real i
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
> I think I have a test case for 7.4.2
Try the attached patch.
It looked to me like there were some smaller leaks going on during COPY
and CREATE INDEX, which I will look into later --- but this seems to be
the problem for VACUUM FULL.
The fact that the estimator knows that the LIMIT is pointless because
there
are less rows in the subselect than the LIMIT will return is not
something we
want to count on; sometimes the estimator has innaccurate information.
The
UNIQUE index makes this more certain, except that I'm not sure
On Mon, 13 Dec 2004 17:43:07 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
Sven Willenberger <[EMAIL PROTECTED]> writes:
explain analyze select storelocation,order_number from custacct where
referrer = 1365 and orderdate between '2004-12-07' and '2004-12-07
12:00:00' order by custacctid limit 10;
I've looked at PREPARE, but apparently it only lasts per-session -
that's
worthless in our case (web based service, one connection per
data-requiring
connection).
You don't use persistent connections ???
Your problem might simply be the connection time overhead (also including
a fe
