Re: ANALYZE sampling is too good

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: ANALYZE sampling is too good
Дата
Msg-id 52A8AE66.3010504@archidevsys.co.nz
обсуждение исходный текст
Ответ на Re: ANALYZE sampling is too good  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/12/13 06:22, Tom Lane wrote:
> I wrote:
>> Hm.  You can only take N rows from a block if there actually are at least
>> N rows in the block.  So the sampling rule I suppose you are using is
>> "select up to N rows from each sampled block" --- and that is going to
>> favor the contents of blocks containing narrower-than-average rows.
> Oh, no, wait: that's backwards.  (I plead insufficient caffeine.)
> Actually, this sampling rule discriminates *against* blocks with
> narrower rows.  You previously argued, correctly I think, that
> sampling all rows on each page introduces no new bias because row
> width cancels out across all sampled pages.  However, if you just
> include up to N rows from each page, then rows on pages with more
> than N rows have a lower probability of being selected, but there's
> no such bias against wider rows.  This explains why you saw smaller
> values of "i" being undersampled.
>
> Had you run the test series all the way up to the max number of
> tuples per block, which is probably a couple hundred in this test,
> I think you'd have seen the bias go away again.  But the takeaway
> point is that we have to sample all tuples per page, not just a
> limited number of them, if we want to change it like this.
>
>             regards, tom lane
>
>
Hmm...

In my previous reply, which hasn't shown up yet!

I realized I made a mistake!

The fraction/probability could any of 0.25. 0.50, and 0.75.


Cheers,
Gavin



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

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: In-Memory Columnar Store