On 9 May 2014 02:40, Stephen Frost <sfrost@snowman.net> wrote:
> * Simon Riggs (simon@2ndQuadrant.com) wrote:
>> On 8 May 2014 20:40, Robert Haas <robertmhaas@gmail.com> wrote:
>> > For my money, we'd be better off
>> > getting some kind of basic custom scan node functionality committed
>> > first, even if the cases where you can actually inject them into real
>> > plans are highly restricted. Then, we could later work on adding more
>> > ways to inject them in more places.
>>
>> We're past the prototyping stage and into productionising what we know
>> works, AFAIK. If that point is not clear, then we need to discuss that
>> first.
>>
>> At the moment the Custom join hook is called every time we attempt to
>> cost a join, with no restriction.
>>
>> I would like to highly restrict this, so that we only consider a
>> CustomJoin node when we have previously said one might be usable and
>> the user has requested this (e.g. enable_foojoin = on)
>
> This is part of what I disagree with- I'd rather not require users to
> know and understand when they want to do a HashJoin vs. a MergeJoin vs.
> a CustomJoinTypeX.
Again, I have *not* said users should know that.
>> We only consider merge joins if the join uses operators with oprcanmerge=true.
>> We only consider hash joins if the join uses operators with oprcanhash=true
>
> I wouldn't consider those generally "user-facing" options, and the
> enable_X counterparts are intended for debugging and not to be used in
> production environments. To the point you make in the other thread- I'm
> fine w/ having similar cost-based enable_X options, but I think we're
> doing our users a disservice if we require that they populate or update
> a table. Perhaps an extension needs to do that on installation, but
> that would need to enable everything to avoid the user having to mess
> around with the table.
Again, I did *not* say those should be user facing options, nor that
they be set at table-level.
What I have said is that authors of CustomJoins or CustomScans should
declare in advance via system catalogs which operators their new code
works with so that Postgres knows when it is appropriate to call them.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
