From: | Kjell Tore Fossbakk <kjelltore(at)gmail(dot)com> |
---|---|
To: | Tobias Brox <tobias(at)nordicbet(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Querying 19million records very slowly |
Date: | 2005-06-22 08:18:30 |
Message-ID: | e79986c5050622011828dd4b41@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Appreciate your time, Mr Brox.
I'll test the use of current_timestamp, rather than now(). I am not
sure if Pg can do a match between a fixed timestamp and a datetime?
time > current_timestamp - interval '24 hours',
when time is yyyy-mm-dd hh-mm-ss+02, like 2005-06-22 16:00:00+02.
If Pg cant do it, and current_time is faster, i could possibly convert
the time field in my database to timestamp, and insert all rows as
timestamp rather than a timedate. But that is some script to work over
19 mill rows, so I need to know if that will give me any more speed..
Kjell Tore.
On 6/22/05, Tobias Brox <tobias(at)nordicbet(dot)com> wrote:
> [Kjell Tore Fossbakk - Wed at 09:45:22AM +0200]
> > database=> explain analyze select count(*) from test where p1=53 and
> > time > now() - interval '24 hours' ;
>
> Sorry to say that I have not followed the entire thread neither read the
> entire email I'm replying to, but I have a quick hint on this one (ref my
> earlier thread about timestamp indices) - the postgresql planner will
> generally behave smarter when using a fixed timestamp (typically generated
> by the app server) than logics based on now().
>
> One of my colleagues also claimed that he found the usage of
> localtimestamp faster than now().
>
> --
> Tobias Brox, +86-13521622905
> Nordicbet, IT dept
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2005-06-22 08:30:51 | Re: Configurator project launched |
Previous Message | Tobias Brox | 2005-06-22 08:03:57 | Re: Querying 19million records very slowly |