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 по дате отправления: