Re: Strange behavior of function date_trunc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Strange behavior of function date_trunc
Date: 2021-05-06 19:14:13
Message-ID: 4175001.1620328453@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrien Nayrat 2021-05-06 19:21:18 Re: "invalid contrecord" error on replica
Previous Message Pavel Luzanov 2021-05-06 16:26:47 Re: Strange behavior of function date_trunc