Re: Problem with large query - Mailing list pgsql-performance

From Marc Cousin
Subject Re: Problem with large query
Date
Msg-id 200409081717.47514.mcousin@sigma.fr
Whole thread Raw
In response to Re: Problem with large query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Wednesday 08 September 2004 16:56, you wrote:
> Marc Cousin <mcousin@sigma.fr> writes:
> > The query has been generated by business objects ... i'ill try to suggest to the developpers to remove this
constant(if they can)... 
> > The fields used by the sort are of type numeric(6,0) or (10,0) ...
> > Could it be better if the fields were integer or anything else ?
>
> integer or bigint would be a WHOLE lot faster.  I'd venture that
> comparing two numerics is order of a hundred times slower than
> comparing two integers.
>
> Even if you don't want to change the fields on-disk, you might think
> about casting them all to int/bigint in the query.
>
> Another thing that might or might not be easy is to change the order of
> the GROUP BY items so that the fields with the largest number of
> distinct values are listed first.  If two rows are distinct at the first
> column, the sorting comparison doesn't even have to look at the
> remaining columns ...
>
>    regards, tom lane
>
Thanks. I've just had confirmation that they can remove the two constants (allready won 100 seconds thanks to that)
I've tried the cast, and got down to 72 seconds.
So now we're going to try to convert the fields to int or bigint.

Thanks a lot for your help and time.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with large query
Next
From: Shridhar Daithankar
Date:
Subject: Re: [GENERAL] Text Search vs MYSQL vs Lucene