Re: [HACKERS] GROUP BY / ORDER BY string is very slow

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] GROUP BY / ORDER BY string is very slow
Дата
Msg-id 36A811B0.12D9E787@alumni.caltech.edu
обсуждение исходный текст
Ответ на GROUP BY / ORDER BY string is very slow  (Oleg Broytmann <phd@sun.med.ru>)
Ответы Re: [HACKERS] GROUP BY / ORDER BY string is very slow  (Oleg Broytmann <phd@sun.med.ru>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] SPI_prepare() doesn't work well ?
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] ecpg docs