Re: [PERFORM] Trigger vs Rule

2006-04-03 Thread Niklas Johansson
On 2 apr 2006, at 23.08, Niklas Johansson wrote: CREATE OR REPLACE FUNCTION exec_device_type() RETURNS trigger AS $$ EXECUTE SELECT device_type || OLD.type || (OLD.id); $$ LANGUAGE plpgsql; Sorry, I was bitten by the bedbug there: a plpgsql function needs a little more than that

Re: [PERFORM] Trigger vs Rule

2006-04-03 Thread Ключников А . С .
* Niklas Johansson [EMAIL PROTECTED] [2006-04-03 11:04:25 +0200]: On 2 apr 2006, at 23.08, Niklas Johansson wrote: CREATE OR REPLACE FUNCTION exec_device_type() RETURNS trigger AS $$ EXECUTE SELECT device_type || OLD.type || (OLD.id); $$ LANGUAGE plpgsql; Sorry, I was bitten by

[PERFORM] Measuring the execution time of functions within functions...

2006-04-03 Thread Mario Splivalo
I have asked this before, but haven't noticed any response, so if there were any, I appologize for asking this again... I have a function that is called by middle-tier (java trough JDBC), and in postgres log I can see only the execution time of that function. I have no idea how long are functions

Re: [PERFORM] Measuring the execution time of functions within functions...

2006-04-03 Thread Alvaro Herrera
Mario Splivalo wrote: Since the function is written in plpgsql I tried to calculate the durations by using now() function, but realized that within the transaction now() always retunrs the same value. Maybe you can use timeofday(). -- Alvaro Herrera

Re: [PERFORM] Measuring the execution time of functions within functions...

2006-04-03 Thread Jerry Sievers
Mario Splivalo [EMAIL PROTECTED] writes: I have asked this before, but haven't noticed any response, so if there were any, I appologize for asking this again... I have a function that is called by middle-tier (java trough JDBC), and in postgres log I can see only the execution time of that

[PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Kenji Morishige
I am using postgresql to be the central database for a variety of tools for our testing infrastructure. We have web tools and CLI tools that require access to machine configuration and other states for automation. We have one tool that uses a table that looks like this: systest_live=# \d cuty

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Josh Berkus
Kenji, We used to use MySQL for these tools and we never had any issues, but I believe it is due to the transactional nature of Postgres that is adding an overhead to this problem.   You're correct. Are there any table options that enables the table contents to be maintained in ram only

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Rajesh Kumar Mallah
Dear Kenji, we had similar issuse with a banner impression update system, that had high concurrency. we modfied the system to use insert instead of update of the same row. performance wise things are much better , but you have to keep deleting old data. hope you extrapolate what i mean if its

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Tom Lane
Kenji Morishige [EMAIL PROTECTED] writes: Various users run a tool that updates this table to determine if the particular resource is available or not. Within a course of a few days, this table can be updated up to 200,000 times. There are only about 3500 records in this table, but the

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Kenji Morishige
I've been stumped as to how to call psql from the command line without it prompting me for a password. Is there a enviornoment variable I can specify for the password or something I can place in .pgsql? I could write a perl wrapper around it, but I've been wondering how I can call psql -c

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Alvaro Herrera
Kenji Morishige wrote: I've been stumped as to how to call psql from the command line without it prompting me for a password. Is there a enviornoment variable I can specify for the password or something I can place in .pgsql? I could write a perl wrapper around it, but I've been wondering

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Kenji Morishige
Sweet! Thanks. -Kenji On Mon, Apr 03, 2006 at 03:03:54PM -0400, Alvaro Herrera wrote: Kenji Morishige wrote: I've been stumped as to how to call psql from the command line without it prompting me for a password. Is there a enviornoment variable I can specify for the password or

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Kenji Morishige wrote: I've been stumped as to how to call psql from the command line without it prompting me for a password. Is there a enviornoment variable I can specify for the password or something I can place in .pgsql? I could write a perl

Re: [PERFORM] optimizing db for small table with tons of updates

2006-04-03 Thread Kenji Morishige
Cool, looks like I had tried the .pgpass thing a while back and wasn't working, I realized I had a typo or something in there. It works like a charm. Security in our intranet is not a big issue at the moment. Thanks for the help! -Kenji On Mon, Apr 03, 2006 at 03:23:50PM -0400, Tom Lane wrote:

[PERFORM] The order of fields around the = in the WHERE conditions

2006-04-03 Thread Mike Quinn
version PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.6 (1 row) -- The order of fields around the = in the WHERE conditions -- affects

[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] bad performance on Solaris 10

2006-04-03 Thread Josh Berkus
Chris, Eons ago PCs had those turbo switches (it was never totally clear why they put them there in the first place, anyway). I've this bad feeling there's a secret turbo switch I can't spot hidden somewhere in Solaris :/ Yes. Check out Jignesh's configuration advice ach, this is

[PERFORM] freebsd/softupdates for data dir

2006-04-03 Thread Miguel
Hi, reading the archives i cant find a clear answer about softupdates in freebsd, is it recommended to enable it for the data directory? --- miguel ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] freebsd/softupdates for data dir

2006-04-03 Thread Mark Kirkwood
Miguel wrote: Hi, reading the archives i cant find a clear answer about softupdates in freebsd, is it recommended to enable it for the data directory? There is a pretty good article about softupdates and journelling here:

Re: [PERFORM] bad performance on Solaris 10

2006-04-03 Thread Luke Lonergan
Title: Re: [PERFORM] bad performance on Solaris 10 Jigneshs blog has some of the good stuff in it: http://blogs.sun.com/roller/page/jkshah - Luke On 4/3/06 5:49 PM, Josh Berkus josh@agliodbs.com wrote: Chris, Eons ago PCs had those turbo switches (it was never totally clear why they put

Re: [PERFORM] bad performance on Solaris 10

2006-04-03 Thread Mark Kirkwood
Chris Mair wrote: 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