Re: ANALYZE sampling is too good

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: ANALYZE sampling is too good
Дата
Msg-id 52A6A452.6070801@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: ANALYZE sampling is too good  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On 10/12/13 17:18, Claudio Freire wrote:
> On Tue, Dec 10, 2013 at 12:13 AM, Mark Kirkwood
> <mark.kirkwood@catalyst.net.nz> wrote:
>> Just one more...
>>
>> The Intel 520 with ext4:
>>
>>
>> Without patch:  ANALYZE pgbench_accounts 5s
>> With patch: ANALYZE pgbench_accounts  1s
>>
>> And double checking -
>> With patch, but effective_io_concurrency = 1: ANALYZE pgbench_accounts  5s
>>
>> These results look more like Heikki's. Which suggests more benefit on SSD
>> than spinning disks. Some more data points (apart from mine) would be good
>> to see tho.
>
> Assuming ANALYZE is sampling less than 5% of the table, I'd say
> fadvising will always be a win.
>
> I'd also suggest higher e_i_c for rotating media. Rotating media has
> longer latencias, and e_i_c has to be computed in terms of latency,
> rather than "spindles" when doing prefetch.
>
> For backward index scans, I found the optimum number for a single
> spindle to be about 20.

Yeah - was just fooling about with this on the velociraptor, looks like 
somewhere in the 20's works well.
                   | pgbench_accounts
eff_io_concurrency | analyze time (s)
-------------------+-----------------
8                  |  43
16                 |  40
24                 |  36
32                 |  35
64                 |  35

Cheers

Mark



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

Предыдущее
От: KONDO Mitsumasa
Дата:
Сообщение: Re: Time-Delayed Standbys
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Get more from indices.