Re: Inconsistent performance

От: Christopher Browne
Тема: Re: Inconsistent performance
Дата: ,
Msg-id: 60d6e1lmph.fsf@dev6.int.libertyrms.info
(см: обсуждение, исходный текст)
Ответ на: Inconsistent performance  (Joseph Bove)
Список: pgsql-performance

Скрыть дерево обсуждения

Inconsistent performance  (Joseph Bove, )
 Re: Inconsistent performance  (Stephan Szabo, )
 Re: Inconsistent performance  (Bruno Wolff III, )
 Re: Inconsistent performance  (Joseph Bove, )
  Re: Inconsistent performance  (Josh Berkus, )
  Re: Inconsistent performance  (Stephan Szabo, )
   Re: Inconsistent performance  (Joseph Bove, )
    Re: Inconsistent performance  ("scott.marlowe", )
     Re: Inconsistent performance  ("scott.marlowe", )
    Re: Inconsistent performance  (Brian Hirt, )
    Re: Inconsistent performance  ("Matt Clark", )
  Re: Inconsistent performance  (Christopher Browne, )
   Re: Inconsistent performance  (Manfred Koizar, )
    Re: Inconsistent performance  (Joseph Bove, )
     Re: Inconsistent performance  (Jeff, )
 Re: Inconsistent performance  (Christopher Browne, )

 (Joseph Bove) writes:
> I do a rather simple query: select count (*) from large-table where
> column = some value;
>
> About 80% of the time, the response time is sub-second. However, at
> 10% of the time, the response time is 5 - 10 seconds.

Does it seem data-dependent?

That is, does the time vary for different values of "some value?"

If a particular value is particularly common, the system might well
revert to a sequential scan, making the assumption that it is quicker
to look at every page in the table rather than to walk through
Enormous Numbers of records.

I had a case very similar to this where a table had _incredible_
skewing of this sort where there were a small number of column values
that occurred hundreds of thousands of times, and other column values
only occurred a handful of times.

I was able to get Excellent Performance back by setting up two partial
indices:
 - One for WHERE THIS_COLUMN > VITAL_VALUE;
 - One for WHERE THIS_COLUMN < VITAL_VALUE;

The REALLY COMMON values were in the range < VITAL_VALUE.
--
output = ("cbbrowne" "@" "libertyrms.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)


В списке pgsql-performance по дате сообщения:

От: Tom Lane
Дата:
Сообщение: Re: restore time: sort_mem vs. checkpoing_segments
От: Manfred Koizar
Дата:
Сообщение: Re: Inconsistent performance