Isaac Morland writes:
> What is confusing me is why the planner can't convert "[entire row] IS
> NULL" into a test for existence of the matching row (assuming there is at
> least one NOT NULL column).
The reasons why the planner does very little with row-level IS [NOT] NULL
conditions are (1) so
On Tue, 22 Jan 2019 at 15:32, Andrew Gierth
wrote:
> > "Isaac" == Isaac Morland writes:
>
> Isaac> So it is as if checking the whole tuple for NULL requires
> Isaac> reading the PDF bytea columns, but checking just the primary key
> Isaac> for NULL or even reading the lengths of the PDFs
> "Isaac" == Isaac Morland writes:
Isaac> So it is as if checking the whole tuple for NULL requires
Isaac> reading the PDF bytea columns, but checking just the primary key
Isaac> for NULL or even reading the lengths of the PDFs does not.
That is almost certainly exactly what happens. If
I'm finding a massive difference in query execution time between two
queries that should be identical:
Very slow:
select ... from x natural left join y where y is null
Fast:
select ... from x natural left join y where y.primary_key_column is null
A fact that I suspect is important is that y has
