Re: Why is the comparison between timestamp and date so much slower then between two dates

From: Alban Hertroys <haramrae(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why is the comparison between timestamp and date so much slower then between two dates
Date: 2016-04-13 14:39:18
Message-ID: CAF-3MvMTxgAoH=zDXDTpyPyB_OCNpuyPFsa_pbLK0=J_NKG+mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 13 April 2016 at 15:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Kellerer <spam_eater(at)gmx(dot)net> writes:
>> So my question is: why is comparing a timestamp to a date so much slower?
>
> The date has to be up-converted to a timestamptz (not timestamp).
> I think the expensive part of that is determining what timezone
> applies, in particular whether DST is active. You could try it
> with "localtimestamp" (no parens) instead of "now()" to see how
> it performs with a non-tz timestamp.
>
> regards, tom lane

Or... you can manually down-convert the timestamptz now() to a date ;)
That's basically what you're doing when you use current_date instead of now().

The reason that the other way around is so much more expensive is that
the database needs to do that conversion twice for every row in the
table. When down-converting now(), the DB only needs to do that once
for all rows.

Regards,
Alban Hertroys.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Edson Richter 2016-04-13 14:46:47 Re: Fastest way to duplicate a quite large database
Previous Message Adrian Klaver 2016-04-13 14:26:11 Re: Freezing localtimestamp and other time function on some value