Re: Selecting max(pk) is slow on empty set

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Selecting max(pk) is slow on empty set
Дата
Msg-id 4796001C.4020804@archonet.com
обсуждение исходный текст
Ответ на Re: Selecting max(pk) is slow on empty set  ("Alexander Staubo" <alex@purefiction.net>)
Ответы Re: Selecting max(pk) is slow on empty set  ("Alexander Staubo" <alex@purefiction.net>)
Список pgsql-general
Alexander Staubo wrote:
> On 1/22/08, Richard Huxton <dev@archonet.com> wrote:
>> Although the row-estimate still seems quite high. You might want to
>> increase it even further (maximum is 1000). If this is a common query,
>> I'd look at an index on (user,id) rather than just (user) perhaps.
>
> Actually that index (with the same statistics setting as before)
> yields slightly worse performance:
>
> # explain analyze select max(id) from user_messages where user_id = 13604;
>  Total runtime: 0.128 ms
>
> Compare with the plain index on the one attribute:
>
> # explain analyze select max(id) from user_messages where user_id = 13604;
>  Total runtime: 0.085 ms

Ah, but:
1. Those times are so small, I'm not sure you can reliably separate
them. Certainly not from one run.
2. For a range of different user-ids I'd expect user_id_id index to
maintain a near-constant time regardless of the number of messages for
that user.
3. You might be able to reduce your statistics on the user column and
still keep the fast plan.

--
   Richard Huxton
   Archonet Ltd

В списке pgsql-general по дате отправления:

Предыдущее
От: "Alexander Staubo"
Дата:
Сообщение: Re: Selecting max(pk) is slow on empty set
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] Errors with run_build.pl - 8.3RC2