Pavel Luzanov <p.luzanov@postgrespro.ru> writes:
> One thing remains unclear.
> Why, if a scalar subquery is used to materialize the function value(even
> constant), then an inefficient index scan is chosen:
The scalar subquery prevents the planner from seeing the actual
comparison value, so it falls back to a default selectivity estimate
(notice the fairly bad rowcount estimate). I'm a bit surprised that
that would end in choosing an indexscan over a seqscan, but that
might be a consequence of the small random_page_cost you're using.
regards, tom lane