Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: schema variables
Дата
Msg-id CAFj8pRBSQDs3SpJ6EV-SP2Gkoc6OwxzCkB8ka7815o3Tw2TkxQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: schema variables  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: [HACKERS] proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hi

2018-09-04 9:21 GMT+02:00 Dean Rasheed <dean.a.rasheed@gmail.com>:
AFAICS this patch does nothing to consider parallel safety -- that is,
as things stand, a variable is allowed in a query that may be
parallelised, but its value is not copied to workers, leading to
incorrect results. For example:

create table foo(a int);
insert into foo select * from generate_series(1,1000000);
create variable zero int;
let zero = 0;

explain (costs off) select count(*) from foo where a%10 = zero;

                  QUERY PLAN
-----------------------------------------------
 Finalize Aggregate
   ->  Gather
         Workers Planned: 2
         ->  Partial Aggregate
               ->  Parallel Seq Scan on foo
                     Filter: ((a % 10) = zero)
(6 rows)

select count(*) from foo where a%10 = zero;

 count
-------
 38037    -- Different random result each time, should be 100,000
(1 row)

Thoughts?

The query use copy of values of variables now - but unfortunately, these values are not passed to workers.  Should be fixed.

Thank you for test case.

Pavel


Regards,
Dean

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pointless check in RelationBuildPartitionDesc
Следующее
От: Amit Khandekar
Дата:
Сообщение: Re: TupleTableSlot abstraction