Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От david@lang.hm
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id alpine.DEB.2.00.1102030208440.8162@asgard.lang.hm
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Vitalii Tymchyshyn <tivv00@gmail.com>)
Ответы Re: [HACKERS] Slow count(*) again...
Re: [HACKERS] Slow count(*) again...
Список pgsql-performance
On Thu, 3 Feb 2011, Vitalii Tymchyshyn wrote:

> 02.02.11 20:32, Robert Haas ???????(??):
>>
>> Yeah.  Any kind of bulk load into an empty table can be a problem,
>> even if it's not temporary.  When you load a bunch of data and then
>> immediately plan a query against it, autoanalyze hasn't had a chance
>> to do its thing yet, so sometimes you get a lousy plan.
>
> May be introducing something like 'AutoAnalyze' threshold will help? I mean
> that any insert/update/delete statement that changes more then x% of table
> (and no less then y records) must do analyze right after it was finished.
> Defaults like x=50 y=10000 should be quite good as for me.

If I am understanding things correctly, a full Analyze is going over all
the data in the table to figure out patterns.

If this is the case, wouldn't it make sense in the situation where you are
loading an entire table from scratch to run the Analyze as you are
processing the data? If you don't want to slow down the main thread that's
inserting the data, you could copy the data to a second thread and do the
analysis while it's still in RAM rather than having to read it off of disk
afterwords.

this doesn't make sense for updates to existing databases, but the use
case of loading a bunch of data and then querying it right away isn't
_that_ uncommon.

David Lang

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

Предыдущее
От: Glyn Astill
Дата:
Сообщение: Re: Which RAID Controllers to pick/avoid?
Следующее
От: Laszlo Nagy
Дата:
Сообщение: Get master-detail relationship metadata