Re: TABLESAMPLE patch
От | Michael Paquier |
---|---|
Тема | Re: TABLESAMPLE patch |
Дата | |
Msg-id | CAB7nPqTbcvbrnTAeXkphWT2gz6TdM4X-zNq+_nnYmQvBGmuckQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TABLESAMPLE patch (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: TABLESAMPLE patch
|
Список | pgsql-hackers |
On Fri, Apr 17, 2015 at 10:54 PM, Petr Jelinek wrote: > On 10/04/15 06:46, Michael Paquier wrote: >> 13) Some regression tests with pg_tablesample_method would be welcome. > > Not sure what you mean by that. I meant a sanity check on pg_tablesample_method to be sure that tsminit, tsmnextblock and tsmnexttuple are always defined as they are mandatory functions. So the idea is to add a query like and and to be sure that it returns no rows: SELECT tsmname FROM pg_tablesample_method WHERE tsminit IS NOT NULL OR tsmnextblock IS NOT NULL OR tsmnexttuple IS NOT NULL; > - Added two sample contrib modules demonstrating row limited and time > limited sampling. I am using linear probing for both of those as the builtin > block sampling is not well suited for row limited or time limited sampling. > For row limited I originally thought of using the Vitter's reservoir > sampling but that does not fit well with the executor as it needs to keep > the reservoir of all the output tuples in memory which would have horrible > memory requirements if the limit was high. The linear probing seems to work > quite well for the use case of "give me 500 random rows from table". Patch 4 is interesting, it shows a direct use of examinetuple to filter the output. -- Michael
В списке pgsql-hackers по дате отправления: