Re: BUG #18588: Cannot force/let database use parallel execution in simple case.
От | Tom Lane |
---|---|
Тема | Re: BUG #18588: Cannot force/let database use parallel execution in simple case. |
Дата | |
Msg-id | 2095917.1724369955@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18588: Cannot force/let database use parallel execution in simple case. (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-bugs |
David Rowley <dgrowleyml@gmail.com> writes: > On Fri, 23 Aug 2024 at 10:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What Maxim is observing is that he's getting I/O concurrency from >> multiple workers; and that's an effect we're simply not accounting >> for here. > I had a look in src/backend/optimizer/README to see if we've defined > what parallel plan costs mean and I didn't see anything under the > "Parallel Query and Partial Paths" heading. I don't see anything in > the header comment to struct Path either. Yeah, it'd be good to have some clarity about that. The whole notion of dividing cost by number of workers seems a little squishy, because we certainly aren't doing less work by having more workers. I guess parallel query has redefined cost as being some measure of elapsed time, which isn't unreasonable but it ought to be written down somewhere. Also, if we're defining it like that, how do we deal with overlap between I/O and computation? regards, tom lane
В списке pgsql-bugs по дате отправления: