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

"Tom Lane" <tgl@sss.pgh.pa.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!