Re: Bunch o' dead code in GEQO

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bunch o' dead code in GEQO
Date: 2004-01-23 05:34:35
Message-ID: 87fze7xm6s.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Where are we going to find a representative test set of
> dozen-or-more- way SQL join queries?

Interesting that you should mention that. I've been thinking for a
while that we need a much more extensive test suite for the query
optimizer. This would allow us to more easily spot regressions in the
optimizer, to get quantifiable data on the effect of optimizer
improvements and optimizations, and it might end up being a good
general-purpose performance benchmark as well.

As far as getting good lotsa-join queries, I think we can either:

(1) generate the queries programmatically

For example, star-schema join queries might be tractable via this
method. One nice benefit of generating the queries via this method
is that it should allow us to scale the number of joins pretty
easily. One downside might be that we wouldn't get the kind of
diversity of queries that #2 might provide.

(2) get the queries manually

This would involve either writing schema and a bunch of queries for
an "example app" (a la the Java Web Store), or getting a sanitized
version of the schema & common queries used by a few large PG
users. The latter might be the better way to go...

We could do both, of course, which might be the way to go.

Any thoughts?

-Neil

P.S. Unfortunately, I'm sufficiently busy right now that I won't be
able to do any work on this any time soon -- I just wanted to toss out
some ideas because I really think it's worth doing. Anyone who's
interested is more than welcome to get started.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-01-23 05:35:14 Re: RFC: bufmgr locking changes
Previous Message Tom Lane 2004-01-23 05:21:25 Re: LWLock/ShmemIndex startup question