Re: [HACKERS] GROUP BY / ORDER BY string is very slow - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] GROUP BY / ORDER BY string is very slow
Date
Msg-id 36A811B0.12D9E787@alumni.caltech.edu
Whole thread Raw
In response to GROUP BY / ORDER BY string is very slow  (Oleg Broytmann <phd@sun.med.ru>)
Responses Re: [HACKERS] GROUP BY / ORDER BY string is very slow  (Oleg Broytmann <phd@sun.med.ru>)
List pgsql-hackers
> Once a month I run a very simple script to put WWW logs into the 
> table.
> What is worse is spped of my queries.
> Why is it so slow? How can I speed it up?

Are you running vacuum after removing your indices? If you don't then
the table storage area does not actually shrink.

> I am running postgres compiled with --enable-locale. that is, for 
> every string comparision there are 2 (two) malloc calls and one 
> strcoll. Can I increase speed turning strcoll off? If so, postgres 
> need a SET command to turn localization temporary off.

How can you "turn localization off" if you have localized strings in
your database? If you build indices without localization, then turn
localization back on, the things are probably hopelessly out of order.

> I remember when I submitted my locale patch there was a discussion on
> how to do it the Right Way, but I didn't remember the conlusion. What
> finally we decided? I want to add command (if I should to) that is
> compliant with other stuff here.

Is the Right Way to implement the NATIONAL CHARACTER type rather than
having the CHAR type be localized? That way, you could have both types
in the same database. Or is that SQL92 feature not widely used or
useful?
                   - Tom


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] SPI_prepare() doesn't work well ?
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] ecpg docs