Re: TABLESAMPLE patch is really in pretty sad shape

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TABLESAMPLE patch is really in pretty sad shape
Date: 2015-07-23 14:01:07
Message-ID: 13943.1437660067@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Petr Jelinek <petr(at)2ndquadrant(dot)com> writes:
> 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.

OK, so "InitSampleScan" for a function called at ExecInitSampleScan time
(which we might as well make optional), and then we'll use BeginSampleScan
for the function that gets the parameters. The restart/ReScan function
goes away since BeginSampleScan will take its place.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-23 14:08:40 Several memory leaks for pg_rewind caused by missing PQclear calls
Previous Message Fabien COELHO 2015-07-23 13:50:16 Re: extend pgbench expressions with functions