Skip site navigation (1) Skip section navigation (2)

Re: Querying 19million records very slowly

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 (view raw or flat)
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
>

In response to

Responses

pgsql-performance by date

Next:From: Andreas PflugDate: 2005-06-22 08:30:51
Subject: Re: Configurator project launched
Previous:From: Tobias BroxDate: 2005-06-22 08:03:57
Subject: Re: Querying 19million records very slowly

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group