Re: [PERFORM] Problem with large query

2004-09-08 Thread Marc Cousin
On Wednesday 08 September 2004 16:56, you wrote: > Marc Cousin <[EMAIL PROTECTED]> 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

Re: [PERFORM] Problem with large query

2004-09-08 Thread Tom Lane
Marc Cousin <[EMAIL PROTECTED]> 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

Re: [PERFORM] Problem with large query

2004-09-08 Thread Marc Cousin
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 ? On Wednesday 08 September 2004

Re: [PERFORM] Problem with large query

2004-09-08 Thread Tom Lane
Marc Cousin <[EMAIL PROTECTED]> writes: > I'm having trouble with a (quite big) query, and can't find a way to make it > faster. Seems like it might help if the thing could use a HashAggregate instead of sort/group. Numeric is not hashable, so having those TO_NUMBER constants in GROUP BY destroy

[PERFORM] Problem with large query

2004-09-08 Thread Marc Cousin
Hi. I hope I'm not asking a too trivial question here... I'm having trouble with a (quite big) query, and can't find a way to make it faster. Here is the information : Tables : sces_vte -> 2753539 rows sces_art -> 602327 sces_fsf -> 8126 sces_frc -> 7763 sces_tps ->