[PERFORM] osdl-dbt3 run results - puzzled by the execution plans

2003-09-18 Thread Jenny Zhang
Our hardware/software configuration: kernel: 2.5.74 distro: RH7.2 pgsql: 7.3.3 CPUS: 8 MHz:700.217 model: Pentium III (Cascades) memory: 829 kB shmmax: 3705032704 We did several sets of runs(repeating runs with the same database parameters) and have the following observation: 1. With

Re: [PERFORM] osdl-dbt3 run results - puzzled by the execution

2003-09-18 Thread Jenny Zhang
Thanks for your prompt reply. On Thu, 2003-09-18 at 16:19, Matt Clark wrote: We thought the large effective_cache_size should lead us to better plans. But we found the opposite. Maybe it's inappropriate for little old me to jump in here, but the plan isn't usually that important compared

Re: [PERFORM] osdl-dbt3 run results - puzzled by the execution

2003-09-19 Thread Jenny Zhang
I posted more results as you requested: On Fri, 2003-09-19 at 08:08, Manfred Koizar wrote: On Thu, 18 Sep 2003 15:36:50 -0700, Jenny Zhang [EMAIL PROTECTED] wrote: We thought the large effective_cache_size should lead us to better plans. But we found the opposite. The common structure

Re: [PERFORM] osdl-dbt3 run results - puzzled by the execution

2003-09-19 Thread Jenny Zhang
On Fri, 2003-09-19 at 06:12, Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: I think this is a pipe dream. Variation in where the data gets laid down on your disk drive would alone create more than that kind of delta. I'm frankly amazed you could get repeatability within 2-3%. I

Re: [PERFORM] TPC-R benchmarks

2003-09-25 Thread Jenny Zhang
I am running TPC-H with scale factor of 1 on RedHat7.2 with the kernel 2.5.74. Q17 can always finish in about 7 seconds on my system. The execution plan is: Aggregate (cost=780402.43..780402.43

Re: [PERFORM] TPC-R benchmarks

2003-09-25 Thread Jenny Zhang
- Aggregate (cost=256892.28..256892.28 rows=1 width=11) - Seq Scan on lineitem (cost=0.00..256892.19 rows=37 w idth=11) Filter: (l_partkey = $0) -Original Message- From: Jenny Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday

[PERFORM] update slows down in pl/pgsql function

2003-12-16 Thread Jenny Zhang
on shopping_cart (cost=0.00..5.01 rows=1 width=144) (actual time=0.22..0.37 rows=1 loops=1) Index Cond: (sc_id = 260706::numeric) Total runtime: 1.87 msec (3 rows) Is it true that using pl/pgsql increases the overhead that much? TIA, Jenny -- Jenny Zhang Open Source Development Lab 12725 SW

Re: [PERFORM] [GENERAL] update slows down in pl/pgsql function

2003-12-16 Thread Jenny Zhang
Oops, I named the var name the same as the column name. Changing it to something else solved the problem. Thanks, Jenny On Tue, 2003-12-16 at 15:54, Stephan Szabo wrote: On Tue, 16 Dec 2003, Jenny Zhang wrote: I have stored procedure written in pl/pgsql which takes about 13 seconds

[PERFORM] query slows under load

2004-01-23 Thread Jenny Zhang
on item (item_order(i_subject)); TIA, -- Jenny Zhang Open Source Development Lab 12725 SW Millikan Way, Suite 400 Beaverton, OR 97005 (503)626-2455 ext 31 ---(end of broadcast)--- TIP 8: explain analyze is your friend