> That's only a superficial problem. You don't even know if or when the
> workers that are launched will all finish up running your particular
> node, because (for example) they might be sent to different children
> of a Parallel Append node above you (AFAICS there is no way for a
> participant
>> But, nworkers_launched is always set to 0 in
>> InitializeDSMForeignScan(), so that won’t work. Any other ideas?
>
> At that state it's simply not yet known how many workers will be
> actually launched (they might not start successfully or such). Why do
> you need to know it there and not la
execution time by about half.
But, nworkers_launched is always set to 0 in InitializeDSMForeignScan(), so
that won’t work. Any other ideas?
— Korry
> On May 15, 2019, at 1:08 PM, Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 12:55:33 -0400, Korry Douglas wrote:
Hi all, I’m working on an FDW that would benefit greatly from parallel foreign
scan. I have implemented the callbacks described
here:https://www.postgresql.org/docs/devel/fdw-callbacks.html#FDW-CALLBACKS-PARALLEL.
and I see a big improvement in certain plans.
My problem is that I can’t seem to
On Sat, Jun 23, 2018 at 8:22 AM, Craig Ringer wrote:
> On 22 June 2018 at 23:26, Korry Douglas
> wrote:
>
>> A few misc comments:
>>
>> In general, +1.
>>
>> It might be nice to move the stack trace code into a separate function
>> (not static to elo
A few misc comments:
In general, +1.
It might be nice to move the stack trace code into a separate function (not
static to elog.c) - I have often found it useful to attach backtraces to
objects so I can debug complex allocation/deallocation problems.
The major expense in capturing a stack trace
