Re: Select on timestamp-day slower than timestamp alone - Mailing list pgsql-performance

From Tom Lane
Subject Re: Select on timestamp-day slower than timestamp alone
Date
Msg-id 24863.1052229548@sss.pgh.pa.us
Whole thread Raw
In response to Re: Select on timestamp-day slower than timestamp alone  (Richard Huxton <dev@archonet.com>)
List pgsql-performance
Richard Huxton <dev@archonet.com> writes:
> Well, the "why" is because the number of rows recommended is so big
> (rows=10253528) - I'm also puzzled why we get "timestamp without time zone".

Because that's what he specified the constant to be.

> Does an explicit cast to "with time zone" help?

Writing the constant as timestamp with time zone would fix it.
Casting after-the-fact would not.

The reason: although both "timestamp minus interval" and "timestamptz
minus interval" are constant-foldable, timestamp-to-timestamptz
conversion is not (because it depends on SET TIMEZONE).  So the
planner has to fall back to a default selectivity estimate.  With real
constants it is able to derive a better estimate.

            regards, tom lane


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Hypothetical suggestions for planner, indexing improvement
Next
From: Reiner Dassing
Date:
Subject: Re: Select on timestamp-day slower than timestamp alone