On Fri, 16 Dec 2005, Mark Kirkwood wrote:
Craig A. James wrote:
What would be cool would be some way the developer could alter the plan,
but they way of doing so would strongly encourage the developer to send the
information to this mailing list. Postgres would essentially say, Ok, you
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
How are star joins different from what we do now?
Various ways of doing them, but all use plans that you wouldn't have
come up with via normal join planning.
Methods:
1. join all N small tables together in a cartesian product, then join to
Yeah it would - an implementation I have seen that I like is where the
developer can supply the *entire* execution plan with a query. This is
complex enough to make casual use unlikely :-), but provides the ability
to try out other plans, and also fix that vital query that must run
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I'm running 8.1 installed from source on a Debian Sarge server. I have a
simple query that I believe I've placed the indexes correctly for, and I
still end up with a seq scan. It makes sense, kinda, but it should be able
to use
OK, so while our bitmap scan allows multiple indexes to be joined to get
to heap rows, a star joins allows multiple dimensions _tables_ to be
joined to index into a larger main fact table --- interesting.
Added to TODO:
* Allow star join optimizations
While our bitmap scan allows multiple
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
How are star joins different from what we do now?
Methods:
1. join all N small tables together in a cartesian product, then join to
main Large table once (rather than N times)
Of course, the reason
I wrote:
However, I submit that it wouldn't pick such a plan anyway, and should
not, because the idea is utterly stupid.
BTW, some experimentation suggests that in fact a star join is already
slower than the regular plan in 8.1. You can force a star-join plan
to be generated like this:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Added to TODO:
* Allow star join optimizations
See my response to Simon for reasons why this doesn't seem like a
particularly good TODO item.
Yes, TODO removed. I thought we were waiting for bitmap joins before
trying star
Tom,
On 12/17/05 10:47 AM, Tom Lane [EMAIL PROTECTED] wrote:
BTW, some experimentation suggests that in fact a star join is already
slower than the regular plan in 8.1. You can force a star-join plan
to be generated like this:
Cool!
We've got Paal's test case in the queue to run, it's
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
How are star joins different from what we do now?
Methods:
1. join all N small tables together in a cartesian product, then join to
main Large table once (rather than N times)
On Sun, Dec 18, 2005 at 02:11:16AM +, Harry Jackson wrote:
The one thing that may be skewing these results is that this was
compiled and installed from source with
./configure CFLAGS='-O2' --with-openssl --enable-thread-safety
I am not sure what the default Debian binary for 7.4.7 is
Tom Lane wrote:
2. transform joins into subselects, then return subselect rows via an
index bitmap. Joins are performed via a bitmap addition process.
Looks like 8.1 pretty much does this right now:
First the basic star:
EXPLAIN ANALYZE
SELECT
d0.dmth,
d1.dat,
I have the following table:
CREATE TABLE timeblock
(
timeblockid int8 NOT NULL,
starttime timestamp,
endtime timestamp,
duration int4,
blocktypeid int8,
domain_id int8,
create_date timestamp,
revision_date timestamp,
scheduleid int8,
CONSTRAINT timeblock_pkey PRIMARY KEY
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
How are star joins different from what we do now?
Methods:
1. join all N small tables together in a cartesian product, then join to
main Large table once
14 matches
Mail list logo
