Re: Bunch o' dead code in GEQO - Mailing list pgsql-hackers

From Neil Conway
Subject Re: Bunch o' dead code in GEQO
Date
Msg-id 87fze7xm6s.fsf@mailbox.samurai.com
Whole thread Raw
In response to Re: Bunch o' dead code in GEQO  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bunch o' dead code in GEQO
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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
viathis method  is that it should allow us to scale the number of joins pretty  easily. One downside might be that we
wouldn'tget 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
gettinga sanitized  version of the schema & common queries used by a few large PG  users. The latter might be the
betterway 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LWLock/ShmemIndex startup question
Next
From: Tom Lane
Date:
Subject: Re: RFC: bufmgr locking changes