On Thu, Oct 31, 2024 at 1:43 PM Bruce Momjian wrote:
> > I am not a fan of this patch. I don't see why _removing_ the
> magnetic
> > part helps because you then have no logic for any 1.2 was chosen.
> >
> > Okay, but we have no documented logic on why 4.0 was chosen either. :)
>
> Uh, we
Bruce Momjian writes:
> On Thu, Oct 24, 2024 at 08:01:11PM -0400, Greg Sabino Mullane wrote:
>> Okay, but we have no documented logic on why 4.0 was chosen either. :)
> Uh, we do, and it is in the docs:
> Random access to mechanical disk storage is normally much more
> expensive
>
On Thu, Oct 24, 2024 at 08:01:11PM -0400, Greg Sabino Mullane wrote:
> On Mon, Oct 14, 2024 at 5:15 PM Bruce Momjian wrote:
>
> I am not a fan of this patch. I don't see why _removing_ the magnetic
> part helps because you then have no logic for any 1.2 was chosen.
>
>
> Okay, but we h
HI Greg Sabino Mullane
Another thing is that you simply change the configuration template is
not effective,
need to modify the DEFAULT_RANDOM_PAGE_COST values
{
{"random_page_cost", PGC_USERSET, QUERY_TUNING_COST,
gettext_noop("Sets the planner's estimate of the cost of a "
"nonsequentially fe
On Fri, 25 Oct 2024 at 13:14, Greg Sabino Mullane wrote:
>
> On Mon, Oct 14, 2024 at 10:20 PM David Rowley wrote:
>>
>> Yeah, I think any effort to change the default value for this setting would
>> require some analysis to prove that the newly proposed default
>> is a more suitable setting than
On Mon, Oct 14, 2024 at 10:20 PM David Rowley wrote:
> Yeah, I think any effort to change the default value for this setting
> would require some analysis to prove that the newly proposed default
> is a more suitable setting than the current default. I mean, why 1.2 and
> not 1.1 or 1.3? Where's
On Mon, Oct 14, 2024 at 5:15 PM Bruce Momjian wrote:
> I am not a fan of this patch. I don't see why _removing_ the magnetic
> part helps because you then have no logic for any 1.2 was chosen.
Okay, but we have no documented logic on why 4.0 was chosen either. :)
I would put the magnetic in a
I wrote:
> I recall that when we settled on 4.0 as a good number for
> spinning-rust drives, it came out of some experimentation that
> I'd done that involved multiple-day-long tests. I don't recall any
> more details than that sadly, but perhaps trawling the mailing list
> archives would yield us
David Rowley writes:
> Yeah, I think any effort to change the default value for this setting
> would require some analysis to prove that the newly proposed default
> is a more suitable setting than the current default. I mean, why 1.2
> and not 1.1 or 1.3? Where's the evidence that 1.2 is the best
On Tue, 15 Oct 2024 at 10:15, Bruce Momjian wrote:
> I am not a fan of this patch. I don't see why _removing_ the magnetic
> part helps because you then have no logic for any 1.2 was chosen. I
> would put the magnetic in a separate paragraph perhaps, and recommend
> 4.0 for it. Also, per-tables
On Mon, Sep 30, 2024 at 10:05:29AM -0400, Greg Sabino Mullane wrote:
> On Fri, Sep 27, 2024 at 12:03 PM Dagfinn Ilmari Mannsåker
> wrote:
>
> It might also be worth mentioning cloudy block storage (e.g. AWS' EBS),
> which is typically backed by SSDs, but has extra network latency.
>
>
>
On Fri, Sep 27, 2024 at 12:03 PM Dagfinn Ilmari Mannsåker
wrote:
> It might also be worth mentioning cloudy block storage (e.g. AWS' EBS),
> which is typically backed by SSDs, but has extra network latency.
>
That seems a little too in the weeds for me, but wording suggestions are
welcome. To ge
Greg Sabino Mullane writes:
> So I'll be brave and throw a number out there: 1.2. And change our
> docs to say wordage like "if you are using an older hard disk drive
> technology, you may want to try raising rpc" to replace our
> fairly-hidden note about SSDs buried in the last sentence - of the
On Fri, 2024-09-27 at 10:07 -0400, Greg Sabino Mullane wrote:
> So I'll be brave and throw a number out there: 1.2.
+1
Laurenz Albe
On Fri, Sep 27, 2024 at 8:07 AM Greg Sabino Mullane
wrote:
> tl;dr let's assume SSDs are popular and HDDs are the exception and flip
> our default
>
> Granted, there are other factors involved, and yes, perhaps we should
> tweak some of the similar settings as well, but ranom_page_cost is the
tl;dr let's assume SSDs are popular and HDDs are the exception and flip our
default
As I write this email, it's the year 2024. I think it is time we lower our
"default" setting of random_page_cost (as set in postgresql.conf.sample and
the docs). Even a decade ago, the current default of 4 was cons
16 matches
Mail list logo
