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 performance)
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
> c
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 sa
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 n
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
-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 si
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. T
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:
http://archives.postgresql.org/pgsql-performanc
samantha mahindrakar wrote:
I am facing performance issues with running scheduled jobs. There are
multiple jobs running on the database ...not necessarily acting on the
same table. Either ways i checked if there was a locking issue, I did
not find any conflicting issues. The program is run over
I am facing performance issues with running scheduled jobs. There are
multiple jobs running on the database ...not necessarily acting on the same
table. Either ways i checked if there was a locking issue, I did not find
any conflicting issues. The program is run over night ..when i check the
lo
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
sock
[...]
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 i
12 matches
Mail list logo
