On Mon, Jul 14, 2025, at 2:41 PM, Tom Lane wrote:
> "Scott Mead" writes:
> > I'd like to re-open the discussion for this commitfest item. I still have
> > not been able to find a value for parallel_setup_cost that makes good
> > decisions about parall
On Wed, May 21, 2025, at 10:55 AM, Scott Mead wrote:
>
>
> On Wed, May 21, 2025, at 3:50 AM, Laurenz Albe wrote:
> > On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> > > On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > > > On Tue, 2025-05
On Wed, May 21, 2025, at 3:50 AM, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> > On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > > On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > > > On Tue, May 13, 2025, at 5:07
On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> > > On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> > > > I'll open by proposi
On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
>> I'll open by proposing that we prevent the planner from automatically
>> selecting parallel plans by default
>
> That seems a pretty heavy hammer
t others think of this proposal. I've dealt with so
many of these over the last 24 months, most of them causing strife along the
way, that I'm interested in what others think.
--
Scott Mead
Amazon Web Services
sc...@meads.us
Note: When testing the attached patch, there are fail
> https://www.EnterpriseDB.com/
> "Someone said that it is at least an order of magnitude more work to do
> production software than a prototype. I think he is wrong by at least
> an order of magnitude." (Brian Kernighan)
>
--
--
Scott Mead
*sc...@meads.us *
>wi_cost_limit = Max(Min(limit,
> worker->wi_cost_limit_base),
> 1);
>
> If we use the max cost_limit as the upper bound here, the worker's
> limit could unnecessarily be higher than the base value in case of
> roundoff trouble? I think that the problem here is rather that we
> don't update wi_cost_limit_base and wi_cost_delay when rebalancing the
> cost.
>
Currently, vacuum always limits you to the cost_limit_base from the time
that your vacuum started. I'm not sure why, I don't believe it's rounding
related because the rest of the rebalancing code works properly. ISTM that
looking simply allowing the updated cost_limit is a simple solution since
the rebalance code will automatically take it into account.
>
> Regards,
>
> --
> Masahiko Sawada
> EDB: https://www.enterprisedb.com/
>
>
>
--
--
Scott Mead
*sc...@meads.us *
gres
(4 rows)
postgres=# exit
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump --help
postgres-# ls
postgres-# cd
postgres-# exit
postgres-# quit
postgres-#
It's not just usability, it's a point of serious frustration for seasoned
database people.
+1
> --
>> Michael
>>
>>
--
--
Scott Mead
Sr. Architect
*OpenSCG <http://openscg.com>*
http://openscg.com
