_id;
END;
'IMMUTABLE LANGUAGE 'plpgsql';
create index i_item_order 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
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 abou
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
Filter: ((p_brand = 'Brand#11'::bpchar) AND
> (p_contai
> ner = 'SM PKG'::bpchar))
>SubPlan
> -> Aggregate (cost=256892.28..256892.28 rows=1
> width=11)
>-> Seq Scan on lineitem (cost=0.00..256
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
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-
On Thu, 2003-09-18 at 20:20, Tom Lane wrote:
> Jenny Zhang <[EMAIL PROTECTED]> writes:
> > ... It seems to me that small
> > effective_cache_size favors the choice of nested loop joins (NLJ)
> > while the big effective_cache_size is in favor of merge joins (MJ).
>
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 op
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 com
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
be interesting to
> see..:-)
>
>
>
Let me know if you have any suggestions about how to improve the test
kit (parameters, reported information, etc.), or how to make it more
useful to PG community.
Thanks,
--
Jenny Zhang
Open Source Development Lab Inc
12725 SW Millikan Way
Suite
only. We plan to improve it so that
it can run against PostgreSQL patches. To find more information about
STP, visit: http://www.osdl.org/stp/.
A sample OSDL-DBT3 test result report can be found at:
http://khack.osdl.org/stp/276912/
Your comments are welcome,
Regards,
Jenny
--
Jenny Zhang
Open
12 matches
Mail list logo
