[HACKERS] why not parallel seq scan for slow functions

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема [HACKERS] why not parallel seq scan for slow functions
Дата
Msg-id CAMkU=1ycXNipvhWuweUVpKuyu6SpNjF=yHWu4c4US5JgVGxtZQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] why not parallel seq scan for slow functions  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
If I have a slow function which is evaluated in a simple seq scan, I do not get parallel execution, even though it would be massively useful.  Unless force_parallel_mode=ON, then I get a dummy parallel plan with one worker.

explain select aid,slow(abalance) from pgbench_accounts;

CREATE OR REPLACE FUNCTION slow(integer)
 RETURNS integer
 LANGUAGE plperl
 IMMUTABLE PARALLEL SAFE STRICT COST 10000000
AS $function$
  my $thing=$_[0];
  foreach (1..1_000_000) {
    $thing = sqrt($thing);
    $thing *= $thing;
  };
  return ($thing+0);
$function$;

The partial path is getting added to the list of paths, it is just not getting chosen, even if parallel_*_cost are set to zero.  Why not?

If I do an aggregate, then it does use parallel workers:

explain select sum(slow(abalance)) from pgbench_accounts;

It doesn't use as many as I would like, because there is a limit based on the logarithm of the table size (I'm using -s 10 and get 3 parallel processes) , but at least I know how to start looking into that.

Also, how do you debug stuff like this?  Are there some gdb tricks to make this easier to introspect into the plans?

Cheers,

Jeff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] pgsql 10: hash indexes testing
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] New partitioning - some feedback