Re: [PERFORM] Trigger question

2004-01-16 Thread Chris Travers
Exists in pg any way to define the trigger execution only if I have changes on some fields? No, but you chould check for those fields and return if no changes have been made. Depending on how intensive the trigger is, this might help. You may also want to look at statement-level triggers or

[PERFORM] subquery and table join, index not use for table

2004-01-16 Thread CoL
Hi, I have to following select: set enable_seqscan = on; set enable_indexscan =on; select a.levelno,a.id from (select 1 as levelno,42 as id) a, menutable b where b.site_id='21' and a.id=b.id; menutable: id bigint, site_id bigint Indexes: menutable_pkey primary key btree (site_id, id), The

[PERFORM] Question about space usage:

2004-01-16 Thread Jeremy M. Guthrie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I recently upgraded from 7.3.4 to 7.4. Besides the PostGreSQL change I updated my schema to pull out all OIDs and 'set storage external'. With PostGreSQL V7.3.4, a completely reindexed and vacuumed(not-full) foot print was 5.2 gig. Now some of

Re: [PERFORM] subquery and table join, index not use for table

2004-01-16 Thread Stephan Szabo
On Wed, 14 Jan 2004, CoL wrote: [plan1] - Seq Scan on menutable b (cost=0.00..13.01 rows=38 width=22) (actual time=0.02..0.38 rows=38 loops=1) [plan2] - Index Scan using menutable_pkey on menutable b (cost=0.00..29.36 rows=38 width=22) (actual time=0.02..0.12 rows=38 loops=1)

Re: [PERFORM] Question about space usage:

2004-01-16 Thread Tom Lane
Jeremy M. Guthrie [EMAIL PROTECTED] writes: With PostGreSQL V7.3.4, a completely reindexed and vacuumed(not-full) foot print was 5.2 gig. Now some of the disk space(probably 10-15 % was waiting in the FSM to be used). However, 7.4 comes up at 2.3 gig. First thought is that your 7.3 DB

Re: [PERFORM] Potential Problem with PostgeSQL performance on SuSE

2004-01-16 Thread Josh Berkus
Mark, Along similar lines - have generally obtained better server performance (and stability) from most Linux distros after replacing their supplied kernel with one from kernel.org . Hmmm any anecdotes about replacing Red Hat 2.4.18 to .24? I've been having problems I can't track down

Re: [PERFORM] Potential Problem with PostgeSQL performance on SuSE

2004-01-16 Thread Mark Kirkwood
We use a server at work that is patched RH 7.3 / 2.4.18 with 2.4.21 (or thereabouts its .24). We have stability issues with Java 1.4 / Tomcat 4.1 but not Pg. It might even be worth building yourself a vanilla 2.4.18 kernel and seeing if that makes any difference... regards Mark Josh Berkus

Re: [PERFORM] Postgres on Netapp

2004-01-16 Thread Larry Rosenman
--On Monday, January 12, 2004 13:45:45 -0800 Shankar K [EMAIL PROTECTED] wrote: Hi There, We are considering to use NetApp filer for a highly busy 24*7 postgres database and the reason we chose netapp, mostly being the snapshot functionality for backing up database online. The filer would be

[PERFORM] Potential Problem with PostgeSQL performance on SuSE Linux 9.0

2004-01-16 Thread Josh Berkus
Folks, While debugging a wireless card, I came across this interesting bit: http://portal.suse.com/sdb/en/2003/10/pohletz_desktop_90.html What it indicates is that by default SuSE 9.0 plays with the timeslice values for the Linux kernel in order to provide a smoother user experience. In my

Re: [PERFORM] Potential Problem with PostgeSQL performance on SuSE

2004-01-16 Thread Mark Kirkwood
Along similar lines - have generally obtained better server performance (and stability) from most Linux distros after replacing their supplied kernel with one from kernel.org . regards Mark Josh Berkus wrote: Folks, While debugging a wireless card, I came across this interesting bit: