Re: [HACKERS] Predicate migration on complex self joins

2009-07-14 Thread Sam Mason
On Mon, Jul 13, 2009 at 07:06:40PM +0100, Simon Riggs wrote: On Mon, 2009-07-13 at 13:33 -0400, Tom Lane wrote: It's hard to believe this sort of case comes up often enough to justify the cycles that would be expended (on *every* join query) to try to recognize it. Yeh, damn ORMs seem to

[HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Simon Riggs
In some cases, we have SQL being submitted that has superfluous self-joins. An example would be select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ and a.c2 = 5 and b.c2 = 10; We can recognise that a and b are the same table because they are joined on the PK. PK is never

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Kevin Grittner
Simon Riggs si...@2ndquadrant.com wrote: select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ You may well ask who would be stupid enough to write SQL like that. The answer is of course that it is automatically generated by an ORM. We had to do something like that to

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: In some cases, we have SQL being submitted that has superfluous self-joins. An example would be select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ and a.c2 = 5 and b.c2 = 10; You may well ask who would be stupid enough to

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Simon Riggs si...@2ndquadrant.com wrote: select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ We had to do something like that to get acceptable performance from Sybase ASE. Writing a join for a single-table query? Why,

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Simon Riggs
On Mon, 2009-07-13 at 13:33 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: In some cases, we have SQL being submitted that has superfluous self-joins. An example would be select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ and a.c2 = 5 and

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Robert Haas
On Mon, Jul 13, 2009 at 1:33 PM, Tom Lanet...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: In some cases, we have SQL being submitted that has superfluous self-joins. An example would be select count(*) from foo1 a, foo1 b where a.c1 = b.c1 /* PK join */ and a.c2 = 5 and

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Writing a join for a single-table query? Why, in heavens name? (Or have you mercifully blotted the details from your memory?) Actually, I had only the vaguest recollection of why, but I found an email where I was explaining the problem to Sybase.

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread decibel
On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote: Not just because of this but I wonder if we might benefit from an optimizer setting specifically aimed at the foolishnesses of automatically generated SQL. +1. And it's not just ORMs that do stupid things, I've seen crap like this come out of

Re: [HACKERS] Predicate migration on complex self joins

2009-07-13 Thread Jaime Casanova
On Mon, Jul 13, 2009 at 3:48 PM, decibeldeci...@decibel.org wrote: On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote: Not just because of this but I wonder if we might benefit from an optimizer setting specifically aimed at the foolishnesses of automatically generated SQL. +1. And it's not