From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maxim Boguk <maxim.boguk@gmail.com>
cc: David Rowley <dgrowleyml@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18588: Cannot force/let database use parallel execution in
 simple case.
In-reply-to: 
 <CAK-MWwS_ZAsaGrz0byqCO38NNrNqPkNt1ww1dorHz_wiaFbWvw@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>
Comments: In-reply-to Maxim Boguk <maxim.boguk@gmail.com>
	message dated "Thu, 22 Aug 2024 20:05:50 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2059549.1724353316.1@sss.pgh.pa.us>
Date: Thu, 22 Aug 2024 15:01:56 -0400
Message-ID: <2059550.1724353316@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2059550.1724353316%40sss.pgh.pa.us>
Precedence: bulk

Maxim Boguk <maxim.boguk@gmail.com> writes:
> Ok there are reproducer test case on the stock postgresql 16.4 config:

Hmm, you can see both behaviors on the small version of t1, just by
varying the comparison constant in the WHERE clause.  For me, it'll
use only one worker with "where a<1", and not parallelize at all
with "where a<0".  It looks like it's deciding that it's not worth
starting workers when too few rows are expected to be returned.  That
would be unsurprising with a normal setting of parallel_setup_cost,
but it does seem odd with parallel_setup_cost=0.

In any case, I think this isn't about the big table being big but
about changing the range of values of "a", which changes the
selectivity of "where a<10" 100-fold.

(I tested on HEAD not v16)

			regards, tom lane