Re: TABLESAMPLE patch is really in pretty sad shape - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: TABLESAMPLE patch is really in pretty sad shape
Date
Msg-id 55B0B998.3010804@2ndquadrant.com
Whole thread Raw
In response to Re: TABLESAMPLE patch is really in pretty sad shape  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TABLESAMPLE patch is really in pretty sad shape
List pgsql-hackers
On 2015-07-23 02:01, Tom Lane wrote:
> This needs to work more like LIMIT, which doesn't try to compute the
> limit parameters until the first fetch.  So what we need is an Init
> function that does very darn little indeed (maybe we don't even need
> it at all), and then a ParamInspect function that is called at first fetch
> or during a ReScan, and that one is the one that gets to look at the
> evaluated parameter values.
>

If we replace the Begin and ReScan interfaces by single interface the 
Init would definitely be optional (all it would do so far is palloc the 
tsmdata which can be done easily in the new interface if tsmdata is 
NULL). I don't like the ParamInspect name as that function needs to 
setup the state for the sampling method (and that's true no matter if we 
have Init or not), I think something like BeginScan works better, but it 
must be clearly documented that it's called for ReScan as well.

> If we wanted to let the method inspect the HeapScanDesc during setup
> it would need still a third callback.  I'm not exactly sure if that's
> worth the trouble.

I tend to agree with this. As I said previously, all that the sampling 
method needs to know should be obtainable via Relation which will be set 
in any case.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: "Thakur, Sameer"
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: "Thakur, Sameer"
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.