From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | markw(at)osdl(dot)org |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposed Query Planner TODO items |
Date: | 2004-10-25 04:59:46 |
Message-ID: | 20041025.135946.39154534.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark,
I see nice graphs for each DBT3 query(for example,
http://developer.osdl.org/markw/dbt3-pgsql/42/q_time.png) It seems
they do not come with normal dbt3-1.4 kit. How did you get them?
Maybe you have slightly modified dbt3 kit?
--
Tatsuo Ishii
> On 6 Feb, To: tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> > On 5 Jan, Tom Lane wrote:
> >> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >>> 2) DEVELOP BETTER PLANS FOR "OR GROUP" QUERIES
> >>
> >>> Summary: Currently, queries with complex "or group" criteria get devolved by
> >>> the planner into canonical and-or filters resulting in very poor execution on
> >>> large data sets. We should find better ways of dealing with these queries,
> >>> for example UNIONing.
> >>
> >>> Description: While helping OSDL with their derivative TPC-R benchmark, we ran
> >>> into a query (#19) which took several hours to complete on PostgreSQL.
>
> http://developer.osdl.org/markw/dbt3-pgsql/
>
> There's a short summary of the tests I ran over the weekend, with links
> to detailed retults. Comparing runs 43 (7.4) and 52 (7.5devel), it
> looks like query #7 had the only significant improvement. Oprofile data
> should be there too, if that'll help. Let us know if there's anything
> else we can try for you.
>
> Mark
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-10-25 07:26:24 | Re: "UNICODE" encoding |
Previous Message | Philip Warner | 2004-10-25 03:29:28 | Re: Using ALTER TABLESPACE in pg_dump |