Re: Why PG uses nested-loop join when no indexes are available?

From: David Grelaud <dgrelaud(at)ideolys(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why PG uses nested-loop join when no indexes are available?
Date: 2016-01-13 17:18:08
Message-ID: CABKm3pggjf_Bo7hd9nvG3SwizXcynE+0ANFfp54GYrOQQYCzyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thank you for your fast response!

I'm sorry, my vocabulary may be not correct and my "french approach" to
explain my problem is not efficient ;).

But the underestimation problem in complex queries is still there? ... and
generates potential "dangerous" plans (nested loop).

We thought at the beginning we were alone but it seems to be a problem of
most database systems.
What do you think about the paragraph 4.1 of this paper
http://www.vldb.org/pvldb/vol9/p204-leis.pdf ?

Regards,
-------------------
David Grelaud,
Ideolys.

2016-01-13 16:02 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> David Grelaud <dgrelaud(at)ideolys(dot)com> writes:
> > Statistics are not propagated when Common Table Expressions (CTE) are
> used.
> > The cardinality of a CTE is equal to 1 most of the time
>
> Really?
>
> The rest of this seems to be proceeding from completely false assumptions.
>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vick Khera 2016-01-13 17:44:33 Re: Moving a large DB (> 500GB) to another DB with different locale
Previous Message Jim Nasby 2016-01-13 17:00:50 Re: Call postgres PL/Python stored function from another PL/Python block.