From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Maxim Boguk <maxim.boguk@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18588: Cannot force/let database use parallel execution in
 simple case.
In-reply-to: 
 <CAApHDvo_nOEKOYLasBKnuw6eYFcObhhpgxq=kEw_G0N0-vx9jA@mail.gmail.com>
References: <18588-204730f9394441a8@postgresql.org>
 <CAApHDvqGgO7c8N0kq5H4jZ0NZe=NGZDo4VVF5Fi5CVdJNbvStg@mail.gmail.com>
 <CAK-MWwTqDRerxrpaN8Xb25DqDGBw1UT+YSkfp4QN-MgOH97c+Q@mail.gmail.com>
 <CAK-MWwS_ZAsaGrz0byqCO38NNrNqPkNt1ww1dorHz_wiaFbWvw@mail.gmail.com>
 <2059550.1724353316@sss.pgh.pa.us> <2073208.1724359323@sss.pgh.pa.us>
 <CAApHDvqVvFz1L-Yxyts+Q4+rbyuOmsJwFK9=pJwQS=cukb+z0g@mail.gmail.com>
 <2088498.1724367160@sss.pgh.pa.us>
 <CAApHDvo_nOEKOYLasBKnuw6eYFcObhhpgxq=kEw_G0N0-vx9jA@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Fri, 23 Aug 2024 11:11:40 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2095916.1724369955.1@sss.pgh.pa.us>
Date: Thu, 22 Aug 2024 19:39:15 -0400
Message-ID: <2095917.1724369955@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2095917.1724369955%40sss.pgh.pa.us>
Precedence: bulk

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