Re: TABLESAMPLE patch - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: TABLESAMPLE patch
Date
Msg-id CAB7nPqTbcvbrnTAeXkphWT2gz6TdM4X-zNq+_nnYmQvBGmuckQ@mail.gmail.com
Whole thread Raw
In response to Re: TABLESAMPLE patch  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: TABLESAMPLE patch
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Next
From: Andrew Dunstan
Date:
Subject: Re: Buildfarm client version 4.15 released