Re: [PERFORM] [pgsql-performance] function difference(geometry,geometry) is SLOW!

2008-06-16 Thread Chris Mair
Date: Mon, 16 Jun 2008 11:06:44 +0200 (CEST) From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: pgsql-performance@postgresql.org Subject: function difference(geometry,geometry) is SLOW! Message-ID: [EMAIL PROTECTED] Hi, In my pgsql procedure, i use the function geometryDiff := difference

Re: [PERFORM] Postgres performance problem

2007-08-27 Thread Chris Mair
Hi, Note: I have already vacumm full. It does not solve the problem. I have a postgres 8.1 database. In the last days I have half traffic than 4 weeks ago, and resources usage is twice. The resource monitor graphs also shows hight peaks (usually there is not peaks) The performarce is getting

Re: [PERFORM] Performance Solaris vs Linux

2007-08-18 Thread Chris Mair
Fredrik Bertilsson wrote: Hi, we are using Postgres on both Solaris servers and Linux servers, and Postgres are much slower on Solaris servers. We have tested with different versions of Solaris and Postgres, but the fact remains: Postgres seems to be much faster on Linux server. Does anybody

Re: [PERFORM] Drop table vs Delete record

2007-05-23 Thread Chris Mair
Hi, with that setup you should vacuum aggressivley. I'd send a vacuum statement in a third thread every 15 minutes or so. The table renaming trick doesn't sound very handy or even necessary... Bye, Chris. Date: Tue, 22 May 2007 14:38:40 -0400 From: Orhan Aglagul [EMAIL PROTECTED] To:

Re: [PERFORM] [pgsql-advocacy] Postgres and really huge tables

2007-01-18 Thread Chris Mair
Is there any experience with Postgresql and really huge tables? I'm talking about terabytes (plural) here in a single table. Obviously the table will be partitioned, and probably spread among several different file systems. Any other tricks I should know about? We have a problem of that

Re: [PERFORM] running benchmark test on a 50GB database

2006-09-20 Thread Chris Mair
I am running bechmark test in a 50 GB postgresql database. I have the postgresql.conf with all parameters by default. In this configuration the database is very, very slow. Could you please tell which is the best configuration? My system: Pentium D 3.0Ghz RAM: 1GB HD: 150GB SATA We

Re: [PERFORM] Reg - Autovacuum

2006-09-12 Thread Chris Mair
Vacuum. http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM And also please suggest other steps that i need to improve the performance . http://www.powerpostgresql.com/PerfList Bye, Chris. -- Chris Mair http://www.1006.org

Re: [PERFORM] [PATCHES] Template0 age is increasing speedily.

2006-09-07 Thread Chris Mair
using. Diagnosing your problem might depend on which OS you use... Finally, explain what you mean by the age of template0 is increasing very rapidly, you mean the size is increasing? Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast

[PERFORM] lowering priority automatically at connection

2006-05-25 Thread Chris Mair
Hi, I find this very helpful: Lowering the priority of a PostgreSQL query http://weblog.bignerdranch.com/?p=11 Now I was wondering whether one could have a SELECT pg_setpriority(10); executed automatically each time a certain user connects (not necessarily using psql)? Any ideas if and

Re: [PERFORM] lowering priority automatically at connection

2006-05-25 Thread Chris Mair
I find this very helpful: Lowering the priority of a PostgreSQL query http://weblog.bignerdranch.com/?p=11 That guy doesn't actually have the foggiest idea what he's doing. The reason there is no built-in capability to do that is that it *does not work well*. Search the list

Re: [PERFORM] Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle

2006-05-18 Thread Chris Mair
Could you give us some more infos about the box' performance while you run the PG benchmark? A few minutes output of vmstat 10 maybe? What does top say? Here, an extract from the vmstat 3 during the test, you can see that my problem is probably a very high disk usage (write and read).

Re: [PERFORM] bad performance on Solaris 10

2006-04-10 Thread Chris Mair
Chris, Just to make sure the x4100 config is similar to your Linux system, can you verify the default setting for disk write cache and make sure they are both enabled or disabled. Here's how to check in Solaris. As root, run format -e - pick a disk - cache - write_cache - display

Re: [PERFORM] bad performance on Solaris 10

2006-04-07 Thread Chris Mair
Ok, so I did a few runs for each of the sync methods, keeping all the rest constant and got this: open_datasync 0.7 fdatasync 4.6 fsync 4.5 fsync_writethrough not supported open_sync 0.6 in arbitrary units - higher is faster. Quite impressive!

Re: [PERFORM] bad performance on Solaris 10

2006-04-06 Thread Chris Mair
Yeah - looks good! (is the default open_datasync still?). Might be worth trying out the fdatasync method too (ISTR this being quite good... again on Solaris 8, so things might have changed)! I was just talking to a member of the Solaris-UFS team who recommended that we test

Re: [PERFORM] bad performance on Solaris 10

2006-04-05 Thread Chris Mair
Doing what http://blogs.sun.com/roller/page/jkshah suggests: wal_sync_method = fsync (unchanged) wal_buffers = 128 (was 8) checkpoint_segments = 128 (was 3) bgwriter_all_percent = 0 (was 0.333) bgwriter_all_maxpages = 0 (was 5) and leaving everything else default

Re: [PERFORM] bad performance on Solaris 10

2006-04-05 Thread Chris Mair
appears this didn't make it to the list... resending to the list directly... --- Doing what http://blogs.sun.com/roller/page/jkshah suggests: wal_sync_method = fsync (unchanged) wal_buffers = 128 (was 8) checkpoint_segments = 128 (was 3) bgwriter_all_percent = 0 (was 0.333)

Re: [PERFORM] bad performance on Solaris 10

2006-04-05 Thread Chris Mair
I've done a few tests. Remounting the fs where $PGDATA lives with forcedirectio (together with logging, that is default) did not help (if not harm...) performance. Sure - forcedirectio on the entire $PGDATA is a definite loss, you only want it on $PGDATA/pg_xlog. The usual

Re: [PERFORM] bad performance on Solaris 10

2006-04-05 Thread Chris Mair
Hi, thanks for all replys. I've done a few tests. Remounting the fs where $PGDATA lives with forcedirectio (together with logging, that is default) did not help (if not harm...) performance. Doing what http://blogs.sun.com/roller/page/jkshah suggests: wal_sync_method = fsync (unchanged)

[PERFORM] bad performance on Solaris 10

2006-04-03 Thread Chris Mair
Hi, I've got a somewhat puzzling performance problem here. I'm trying to do a few tests with PostgreSQL 8.1.3 under Solaris (an OS I'm sort of a newbie in). The machine is a X4100 and the OS is Solaris 10 1/06 fresh install according to manual. It's got two SAS disks in RAID 1, 4GB of RAM. Now

Re: [PERFORM] big databases hospitals

2006-01-14 Thread Chris Mair
Additionally, because this company develops hospital information systems, if someone knows about a medical institute, which uses Postgresql, and happy, please send me infomation. I only now subscribed to the advocacy list, and only started to browse the archives. Hi, have you seen this case

Re: [PERFORM] insertion of bytea

2005-10-27 Thread Chris Mair
On Tue, Oct 25, 2005 at 03:44:36PM +0200, Chris Mair wrote: Is there a better, faster way to do these inserts? COPY is generally the fastest way to do bulk inserts (see PQputCopyData). Hi, I've rewritten the testclient now to use COPY, but I'm getting the exact same results as when doing

[PERFORM] insertion of bytea

2005-10-25 Thread Chris Mair
Hi, I have the following test setup: * PG 8.0.4 on Linux (Centos 4) compiled from source. * DB schema: essentially one table with a few int columns and one bytea column that stores blobs of 52000 bytes each, a primary key on one of the int columns. * A test client was written in C using

Re: [PERFORM] insertion of bytea

2005-10-25 Thread Chris Mair
Is there a better, faster way to do these inserts? COPY is generally the fastest way to do bulk inserts (see PQputCopyData). Thanks :) I'll give that I try and report the results here later. Bye, Chris. ---(end of broadcast)--- TIP 4: Have

Re: [PERFORM] insertion of bytea

2005-10-25 Thread Chris Mair
Am I correct in assuming that even though I'm passing my 52000 bytes as a (char *) to PQexecPrepared(), encoding/decoding is happening (think 0 - \000) somewhere in the transfer? Are you specifying it as a text or binary parameter? Have you looked to see if the stored data is what you

Re: [PERFORM] Data Selection Slow From VB 6.0

2005-08-17 Thread Chris Mair
When I fire a query to search a debtor id, it took around 5 seconds to return an answer for a query [...] Are you sure that time is actually spent in the database engine? Maybe there are DNS resolving issues or something... Did you try to execute the queries directly on the server from the

Re: [PERFORM] PostgresSQL vs. Firebird

2005-07-15 Thread Chris Mair
On Thu, 2005-07-14 at 00:19 -0700, Relaxin wrote: Before I ask, I don't want to start a war. Can someone here give me an honest opinion of how PostgresSQL (PG) is better than Firebird on Windows? A colleague of mine has made some benchmarks using those two:

[PERFORM] interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync

2005-03-15 Thread Chris Mair
Hello, just recently I held a short course on PG. One course attendant, Robert Dollinger, got interested in benchmarking single inserts (since he currently maintains an application that does exactly that on Firebird and speed is an issue there). He came up with a table that I think is

Re: [PERFORM] poor performance of db?

2005-01-24 Thread Chris Mair
I then re-wrote the page to use a single select query to call all the information needed by PHP to draw the screen. That managed to shave it down to 3.5 seconds... but this so far is as fast as I can get the page to load. Have tried vacuuming and creating indexes but to no avail. (increasing