Em dom., 17 de mai. de 2020 às 10:31, Justin Pryzby
escreveu:
> On Sun, May 17, 2020 at 09:32:47AM -0300, Ranier Vilela wrote:
> > I redid the same tests with vanila postgres and with empty tables.
> > I'm surprised, why does the plan have 2550 rows in explain?
>
> That's the *estimated* rowcount
On Sun, May 17, 2020 at 09:32:47AM -0300, Ranier Vilela wrote:
> I redid the same tests with vanila postgres and with empty tables.
> I'm surprised, why does the plan have 2550 rows in explain?
That's the *estimated* rowcount.
The planner tends to ignore table statistics which say the table is em
I redid the same tests with vanila postgres and with empty tables.
I'm surprised, why does the plan have 2550 rows in explain?
regards,
Ranier Vilela
But foo cannot be empty given the foreign key constraint on bar.foo_id.
I suppose that explains the planner's behavior. While today's planner can take
a shortcut when it finds a unique constraint, it does not check for foreign key
constraints matching the join condition? So the LEFT JOIN simplif
> Am I missing a situation where these joins could impact the result?
Yes it will impact the number of rows in the result. for example if foo is
empty then postgres is required to return no results, regardless of how many
rows are in bar. This is why it can ignore the table in the left join
— D
I noticed something peculiar while optimizing complex views today. The query
planner does not skip inner joins that, to my understanding, can have no impact
on the result. Am I missing a situation where these joins could impact the
result?
The following demonstrates the problem without the comp
