On Tue, Jul 14, 2015 at 4:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think this ties into my core unhappiness with the customscan stuff,
> which is that I don't believe it's *possible* to do anything of very
> great interest with it. I think anything really useful will require
> core code modifications and/or hooks that don't exist now. So a finger
> exercise like ctidscan, even though it might have some marginal use,
> doesn't do much to alleviate that concern. It certainly doesn't seem
> like it's a suitable placeholder proving that we aren't breaking any
> actual use cases for the feature.
Both you and Andres have articulated the concern that CustomScan isn't
actually useful, but I still don't really understand why not. KaiGai
has got working code (under a GPL license) that shows that it can be
used for what he calls GpuScan and GpuJoin, and the speedups are
actually pretty cool if you happen to have the right sort of query to
take advantage of it. That code may be buggy and the license
precludes us using it anyway, but FWICT it does seem to work. I'd be
entirely amenable to improving the infrastructure such that it could
be used for a broader array of purposes, and I'm also amenable to
adding more hooks if we need more hooks to make it useful, but I'm not
clear at all on what you think is missing.
I'm curious, for example, whether CustomScan would have been
sufficient to build TABLESAMPLE, and if not, why not. Obviously the
syntax has to be in core, but why couldn't the syntax just call an
extension-provided callback that returns a custom scan, instead of
having a node just for TABLESAMPLE?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company