Re: Parallel safety of CURRENT_* family
От | Robert Haas |
---|---|
Тема | Re: Parallel safety of CURRENT_* family |
Дата | |
Msg-id | CA+Tgmob7cFxSyqozHmp0R2v-Odyj9VFWjLoeHWCWgd3_j6NjSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel safety of CURRENT_* family (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Parallel safety of CURRENT_* family
|
Список | pgsql-hackers |
On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> ... well, they would be if we passed down xactStartTimestamp to parallel >>> workers, but I can't find any code that does that. In view of the fact that >>> transaction_timestamp() is marked as parallel-safe, this is a bug in 9.6. > >> Yeah. Do you think we should arrange to pass that down, or change the marking? > > We can't fix the marking in existing 9.6 installations, so I think we > have to pass it down. (Which would be a better response anyway.) > > Having said that, I find myself unable to reproduce a problem. > This should fail: > > regression=# set parallel_setup_cost TO 0; > SET > regression=# set parallel_tuple_cost TO 0; > SET > regression=# set min_parallel_relation_size TO 0; > SET > regression=# set enable_indexscan TO 0; > SET > regression=# explain verbose select distinct transaction_timestamp() from tenk1; > QUERY PLAN > -------------------------------------------------------------------------------------- > Unique (cost=0.00..424.67 rows=1 width=8) > Output: (transaction_timestamp()) > -> Gather (cost=0.00..424.67 rows=10000 width=8) > Output: (transaction_timestamp()) > Workers Planned: 2 > -> Parallel Seq Scan on public.tenk1 (cost=0.00..410.08 rows=4167 width=8) > Output: transaction_timestamp() > (7 rows) > > but it doesn't: > > regression=# select distinct transaction_timestamp() from tenk1; > transaction_timestamp > ------------------------------- > 2016-12-01 15:44:12.839417-05 > (1 row) > > How is that happening? Because the table is so small, the leader probably finishes running the whole plan before the workers finish starting up. You can see the problem like this, though: rhaas=# begin; BEGIN rhaas=# select transaction_timestamp(); transaction_timestamp -------------------------------2016-12-01 15:51:14.443116-05 (1 row) rhaas=# select transaction_timestamp(); transaction_timestamp -------------------------------2016-12-01 15:51:14.443116-05 (1 row) rhaas=# select transaction_timestamp(); transaction_timestamp -------------------------------2016-12-01 15:51:14.443116-05 (1 row) rhaas=# set force_parallel_mode = true; SET rhaas=# select transaction_timestamp(); transaction_timestamp -------------------------------2016-12-01 15:51:26.603302-05 (1 row) rhaas=# select transaction_timestamp(); transaction_timestamp -------------------------------2016-12-01 15:51:27.316032-05 (1 row) force_parallel_mode causes the whole plan to be run by the worker, without any participation by the leader. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: