Re: [PERFORM] self join revisited

2009-04-01 Thread Robert Haas
> Can I try again? :) > > How hard would it be to teach the planner about preserving uniqueness of > relations in subqueries? > And using that information to remove unnecessary self joins on unique sets? > > I can try to rewrite some queries to test it on real data for how much > gain it would prov

Re: [PERFORM] self join revisited

2009-04-01 Thread Rikard Pavelic
Tom Lane wrote: > Rikard Pavelic writes: > >> It would be great if Postgres could rewrite this query >> > > AFAICS those queries are not going to produce the same results, > so Postgres would be 100% incorrect to rewrite it like that for you. > > (If they do produce the same results, it wo

Re: [PERFORM] self join revisited

2009-04-01 Thread Tom Lane
Rikard Pavelic writes: > It would be great if Postgres could rewrite this query AFAICS those queries are not going to produce the same results, so Postgres would be 100% incorrect to rewrite it like that for you. (If they do produce the same results, it would depend on a bunch of assumptions you

Re: [PERFORM] self join revisited

2009-04-01 Thread Matthew Wakeling
On Wed, 1 Apr 2009, Rikard Pavelic wrote: It would be great if Postgres could rewrite this query SELECT bt1.id, bt1.total, sq.id, sq.total FROM big_table bt1 INNER JOIN small_table st1 on st1.big_id = bt1.id INNER JOIN ( SELECT bt2.id, st2.total

[PERFORM] self join revisited

2009-04-01 Thread Rikard Pavelic
How hard would it be to teach planer to optimize self join? While this query which demonstrates it is not that common SELECT count(*) FROM big_table a INNER JOIN big_table b ON a.id = b.id; This type of query (self joining large table) is very common (at least in our environment