On 03/03/2017 17:33, Tom Lane wrote:
Martin F writes:
The select with filter choose an IMHO better plan
Index Only Scan using tbl_foo_date on public.tbl_foo
But the bigger picture here, which would become more obvious if you were
working with a non-toy amount of data, is that you're asking th
On 03/03/2017 17:33, Tom Lane wrote:
Martin F writes:
Index Cond: (tbl_foo.id IS NOT NULL)
only "id" is the pk, and declared "not null".
So why this index condition?
You're right that we could observe that the NOT NULL is implied by a table
constraint and drop it, but it seems unlikely to
Hi,
following up my own post:
I noted that I included the "set enable_seqscan=off; ". But the results
I mentioned are from before this statement.
I also compared some more statements
explain analyze verbose select min(id) from tbl_foo where created_at >=
'2017-01-15' ;
explain analyze verbo
Martin F writes:
>Index Cond: (tbl_foo.id IS NOT NULL)
> only "id" is the pk, and declared "not null".
> So why this index condition?
The IS NOT NULL condition is generated as part of transforming a "min(x)"
query into an indexscan, on the basis that "select min(x) from ..." is
equivalent to
Hi,
following up my own post:
I noted that I included the "set enable_seqscan=off; ". But the results
I mentioned are from before this statement.
I also compared some more statements
explain analyze verbose select min(id) from tbl_foo where created_at >=
'2017-01-15' ;
explain analyze verbo
Hi.
I am new, and not sure which mailinglist this should go to, so I start
with the general list. (please advice, if I should send this to a more
specific list)
This is tested with postgresql 9.5.5 (Maybe someone can confirm, if it
is the same with later versions, saving me the work to upgrade
