Re: BUG #18588: Cannot force/let database use parallel execution in simple case.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18588: Cannot force/let database use parallel execution in simple case.
Date: 2024-08-22 23:39:15
Message-ID: 2095917.1724369955@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 23 Aug 2024 at 10:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andy Fan 2024-08-23 01:47:45 Re: BUG #18588: Cannot force/let database use parallel execution in simple case.
Previous Message David Rowley 2024-08-22 23:11:40 Re: BUG #18588: Cannot force/let database use parallel execution in simple case.