Re: TABLESAMPLE patch is really in pretty sad shape

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: TABLESAMPLE patch is really in pretty sad shape
Дата
Msg-id 55B0B998.3010804@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: TABLESAMPLE patch is really in pretty sad shape  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: TABLESAMPLE patch is really in pretty sad shape
Список 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 по дате отправления:

Предыдущее
От: "Thakur, Sameer"
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.
Следующее
От: "Thakur, Sameer"
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.