Greg Smith wrote:
CFQ/Deadline/AS are I/O scheduler choices. What changed completely in
2.6.23 is the kernel process scheduler.
http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt
gives some info about the new one.
While the switch to CFS has shown great improvements in terms
[...]
You can check this too:
select relname, relpages, reltuples, relkind
from pg_class
where relkind in ('r', 'i')
order by relpages desc limit 20;
Will give you the top-20 tables and their sizes, 1 page is typically
8KB, so you can cross-check if relpages/reltuples is completly off,
this
Thanks to everyone who replied. There were some really good points.
However, I found what is causing the difference. The perl program was
connecting to the database via a TCP socket while the C version was using Unix
socket. I changed the connect in my perl script, so that it now uses Unix
Hi,
Finally found the problem.
Turning off nested loops gave me much better performance on 8.3 than 8.1.
The problem seems to come from postgresql miscalculation of the number
of rows returned by nested loops.
It is well described in that thread:
Windows 2003 Server SP2
Intel Xeon 3.2 GHz
3.75 Gb RAM
System Drive 33.8 Gb
Data drive 956 Gb
PostgreSQL 8.2.6
PERC RAID 10 I believe SCSI disks
On 7/22/08, Craig Ringer [EMAIL PROTECTED] wrote:
samantha mahindrakar wrote:
I am facing performance issues with running scheduled jobs. There
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In case someone is wondering, the way to force DBI to use unix
sockets is by not specifying a host and port in the connect call.
Actually, the host defaults to the local socket. Using the port
may still be needed: if you leave it out, it
On Tue, 22 Jul 2008, Stephane Bailliez wrote:
I'm 'migrating' (read entirely changing schemas, 'migrating' data) is
coming out from a 8.1.11 install. It is not a critical system. The
source data is always available from another system and the postgresql
system would be a 'client'. So if 8.2.x
On Tue, Jul 22, 2008 at 9:48 AM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
In case someone is wondering, the way to force DBI to use unix
sockets is by not specifying a host and port in the connect call.
Actually, the host defaults to the local socket. Using the port
may still be needed:
For background, please read the thread Fusion-io ioDrive, archived at
http://archives.postgresql.org/pgsql-performance/2008-07/msg00010.php
To recap, I tested an ioDrive versus a 6-disk RAID with pgbench on an
ordinary PC. I now also have a 32GB Samsung SATA SSD, and I have tested
it in the
On Tue, Jul 22, 2008 at 6:04 PM, Jeffrey W. Baker [EMAIL PROTECTED] wrote:
Strangely the RAID controller behaves badly on the TPC-B workload. It
is faster than disk, but not by a lot, and it's much slower than the
other flash configurations. The read/write benchmark did not vary when
samantha mahindrakar wrote:
Windows 2003 Server SP2
Intel Xeon 3.2 GHz
3.75 Gb RAM
System Drive 33.8 Gb
Data drive 956 Gb
PostgreSQL 8.2.6
PERC RAID 10 I believe SCSI disks
... all of which look fairly reasonable, though you didn't say how many
disks (which is *very* important for
11 matches
Mail list logo
