On 7/25/25 17:34, Paul A Jungwirth wrote:
> On Thu, Jul 24, 2025 at 12:09 PM Robert Haas wrote:
>> I think that the motivating use case for the existing support was
>> wanting to offload work to something that looks altogether unlike the
>> normal PostgreSQL executor, rather than (as you want t
On Thu, Jul 24, 2025 at 12:09 PM Robert Haas wrote:
> I think that the motivating use case for the existing support was
> wanting to offload work to something that looks altogether unlike the
> normal PostgreSQL executor, rather than (as you want to do) implement
> a new type of join within the Po
On Thu, Jul 24, 2025 at 12:48 PM Tomas Vondra wrote:
> I was thinking about this a bit more, and I think the CustomScan join
> essentially has to construct it's own info how to build the tuple, most
> likely in PlanCustomPath, because once setrefs.c does it's thing it's
> way too late for that I t
On 7/24/25 15:57, Robert Haas wrote:
> On Thu, Jul 24, 2025 at 9:04 AM Tomas Vondra wrote:
>> With this patch, my custom join can simply do
>>
>> econtext->ecxt_outertuple = outer;
>> econtext->ecxt_innertuple = inner;
>>
>> return ExecProject(node->js.ps.ps_ProjInfo);
>>
>> and it wor
On Thu, Jul 24, 2025 at 9:04 AM Tomas Vondra wrote:
> With this patch, my custom join can simply do
>
> econtext->ecxt_outertuple = outer;
> econtext->ecxt_innertuple = inner;
>
> return ExecProject(node->js.ps.ps_ProjInfo);
>
> and it works.
This doesn't seem like the right approach
Hi,
I've been experimenting with executor nodes inspired by papers on
executor robustness (think "Algorithms that don't explode if an estimate
is off."). And I decided to use the CustomScan API, because it seemed
like an ideal solution for my experiments - convenient, isolated, easy
to try on othe
