Re: mal advice in FAQ 4.1.
| От | Nikolay Samokhvalov |
|---|---|
| Тема | Re: mal advice in FAQ 4.1. |
| Дата | |
| Msg-id | e431ff4c0710090552y79af2b31gb159eb8e9ccf9bd6@mail.gmail.com обсуждение исходный текст |
| Ответ на | mal advice in FAQ 4.1. ("Pavel Stehule" <pavel.stehule@gmail.com>) |
| Ответы |
Re: mal advice in FAQ 4.1.
Re: mal advice in FAQ 4.1. |
| Список | pgsql-hackers |
Hubert recently posted his thoughts on this topic: http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/
I've encountered with this problem several times in web development and every time found out that the best (in terms of performance) solution is to use some pseudo random approach (such as ">= random() limit 1" or "limit 1 offset random()*N" or even pre-caching rows on app side).
--
Best regards,
Nikolay
I've encountered with this problem several times in web development and every time found out that the best (in terms of performance) solution is to use some pseudo random approach (such as ">= random() limit 1" or "limit 1 offset random()*N" or even pre-caching rows on app side).
On 10/9/07, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hello
I found lot of slow queries in some databases which I checked based on
advice 4.1. from FAQ,
To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
It's robust and slow on bigger tables. Can we add some better solutions?
--
Best regards,
Nikolay
В списке pgsql-hackers по дате отправления: