* Simon Riggs (si...@2ndquadrant.com) wrote: > On 8 May 2014 13:48, Stephen Frost <sfr...@snowman.net> wrote: > > I don't view on-GPU memory as being an alternate *permanent* data store. > > As I've said, others have expressed an interest in placing specific > data on specific external resources that we would like to use to speed > up queries. That might be termed a "cache" of various kinds or it > might be simply be an allocation of that resource to a specific > purpose.
I don't think some generalized structure that addresses the goals of
FDWs, CustomPaths, MatViews and query cacheing is going to be workable
and I'm definitely against having to specify at a per-relation level
when I want certain join types to be considered.
> > Perhaps that's the disconnect that we have here, as it was my
> > understanding that we're talking about using GPUs to make queries run
> > faster where the data comes from regular tables.
>
> I'm trying to consider a group of use cases, so we get a generic API
> that is useful to many people, not just to one use case. I had
> understood the argument to be there must be multiple potential users
> of an API before we allow it.
The API you've outlined requires users to specify on a per-relation
basis what join types are valid. As for if CustomPlans, there's
certainly potential for many use-cases there beyond just GPUs. What I'm
unsure about is if any others would actually need to be implemented
externally as the GPU-related work seems to need or if we would just
implement those other join types in core.
Thanks,
Stephen
signature.asc
Description: Digital signature
