Re: Querying 19million records very slowly - Mailing list pgsql-performance

From Kjell Tore Fossbakk
Subject Re: Querying 19million records very slowly
Date
Msg-id e79986c50506220210578776e@mail.gmail.com
Whole thread Raw
In response to Re: Querying 19million records very slowly  (Michael Glaesemann <grzm@myrealbox.com>)
Responses Re: Querying 19million records very slowly  (Tobias Brox <tobias@nordicbet.com>)
List pgsql-performance
> Try to type in '2005-06-21 16:36:22+08' directly in the query, and see if it
> makes changes.  Or probably '2005-06-21 10:36:22+02' in your case ;-)

Which one does Pg read fastes? Does he convert datetime in the table,
then my where clause and check, for each row? How does he compare a
datetime with a datetime? Timestamp are easy, large number bigger than
another large number..

time (datetime) > '2005-06-21 10:36:22+02'

or

time (timestamp) > 'some timestamp pointing to yesterday'

Hmm.. I cant find any doc that describes this very good.


On 6/22/05, Michael Glaesemann <grzm@myrealbox.com> wrote:
>
> On Jun 22, 2005, at 5:39 PM, Tobias Brox wrote:
>
> > (btw, does postgresql really handles timezones?  '+02' is quite
> > different
> > from 'CET', which will be obvious sometime in the late autoumn...)
>
> Yes, it does. It doesn't (currently) record the time zone name, but
> rather only the offset from UTC. If a time zone name (rather than UTC
> offset) is given, it is converted to the UTC offset *at that
> timestamptz* when it is stored. For time zones that take into account
> DST, their UTC offset changes during the year, and PostgreSQL records
> the equivalent UTC offset for the appropriate timestamptz values.
>
> There has been discussion in the past on storing the time zone name
> with the timestamptz as well, though no one has implemented this yet.
>
> Michael Glaesemann
> grzm myrealbox com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

pgsql-performance by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: Querying 19million records very slowly
Next
From: "Markus Wollny"
Date:
Subject: Forums & tsearch2 - best practices reg. concurrency