Re: BUG #3826: Very Slow Execution of examplequery (wrong plan?)

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> It's possible that MS-SQL is doing something analogous to the
> hashed-subplan approach (hopefully with suitable tweaking for the NULL
> case) but even then it's hard to see how it could take only 9 sec.
> The cartesian product is too big.

Fwiw it seems MS-SQL is doing something funny. The three plans posted in the
screenshots for the "small", "mediu", and "large" cases are:

Top
Sort (Distinct Sort)
Nested Loop (Left Anti Semi Join)
Nested Loop
Table Scan
Table Scan
Top
Table Scan

[cut off by the screenshot] Match
Hash Match (Right Anti Semi Join)
Table Scan
Nested Loop
Table Scan
Table Scan

Hash Match (Right Anti Semi Join)
Parallelism (Repartition Streams)
Table Scan
Parallelism (Repartition Streams)
Nested Loop (Inner Join)
Table Scan
Table Spool (Lazy Spool)
Table Scan

Postgres is doing something equivalent to the first plan.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!