[PERFORM] function not called if part of aggregate

2006-06-11 Thread Craig A. James
My application has a function, call it "foo()", that requires initialization from a table of about 800 values. Rather than build these values into the C code, it seemed like a good idea to put them on a PG table and create a second function, call it "foo_init()", which is called for each value

Re: [PERFORM] function not called if part of aggregate

2006-06-11 Thread Steinar H. Gunderson
On Sun, Jun 11, 2006 at 10:18:20AM -0700, Craig A. James wrote: > This works well, but it requires me to actually retrieve the function's > value 800 times. Is this actually a problem? > So I thought I'd be clever: > > select count(1) from (select foo_init(value) from foo_init_table order by

Re: [PERFORM] function not called if part of aggregate

2006-06-11 Thread Tom Lane
"Craig A. James" <[EMAIL PROTECTED]> writes: >select count(1) from (select foo_init(value) from foo_init_table order by > value_id) as foo; > And indeed, it count() returns 800, as expected. But my function foo_init() > never gets called! Really? With the ORDER BY in there, it does get ca

Re: [PERFORM] function not called if part of aggregate

2006-06-11 Thread Jim C. Nasby
On Sun, Jun 11, 2006 at 10:18:20AM -0700, Craig A. James wrote: > This doesn't seem right to me -- how can the optimizer possibly know that a > function doesn't have a side effect, as in my case? Functions could do all > sorts of things, such as logging activity, filling in other tables, etc, >

Re: [PERFORM] function not called if part of aggregate

2006-06-11 Thread Greg Stark
"Craig A. James" <[EMAIL PROTECTED]> writes: > This doesn't seem right to me -- how can the optimizer possibly know that a > function doesn't have a side effect, as in my case? Functions could do all > sorts of things, such as logging activity, filling in other tables, etc, etc. The optimizer ca

Re: [PERFORM] scaling up postgres

2006-06-11 Thread Steinar H. Gunderson
On Sun, Jun 11, 2006 at 11:42:20PM +0200, Mario Splivalo wrote: > Could you point out to some more detailed reading on why Xeons are > poorer choice than Opterons when used with PostgreSQL? There are lots of theories, none conclusive, but the benchmarks certainly point that way consistently. Read

Re: [PERFORM] scaling up postgres

2006-06-11 Thread Mario Splivalo
On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote: > On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote: > > I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC) > > One beast will be apache, and the other will be postgres. > > I'm using httperf/autobench for m

Re: [PERFORM] scaling up postgres

2006-06-11 Thread Joshua D. Drake
Mario Splivalo wrote: On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote: On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote: I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC) One beast will be apache, and the other will be postgres. I'm using httperf/aut

Re: [PERFORM] Variation between query runtimes

2006-06-11 Thread Qingqing Zhou
""John Top-k apad"" <[EMAIL PROTECTED]> wrote > > from pg_stast_get_blocks_fetched i can see that both queries need almost the > same number of disk fetches which is quite reasonable ( the index is > unclustered). > > But as you can see there is a great variation between query > runtimes.Cansomeon

Re: [PERFORM] pgsql_tmp and postgres settings

2006-06-11 Thread Gourish Singbal
  Where is the pgsql_tmp folder present ?.  i am unable to see it in the data directory of postgresql.   ~gourish  On 6/9/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: On Fri, Jun 09, 2006 at 02:23:04PM +0200, Domenico - Sal. F.lli Riva wrote:> Hello,>> During insert or update, potgresql write in pg