Re: Changing the default random_page_cost value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Changing the default random_page_cost value
Date: 2024-10-15 03:03:59
Message-ID: 3866858.1728961439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 useful info. It looks like the 4.0 value came
> in with b1577a7c7 of 2000-02-15, so late 1999/early 2000 would be the
> time frame to look in.

I tried asking https://www.postgresql.org/search/ about
random_page_cost, and got nothing except search engine timeouts :-(.
However, some digging in my own local archives yielded

https://www.postgresql.org/message-id/flat/25387.948414692%40sss.pgh.pa.us

https://www.postgresql.org/message-id/flat/14601.949786166%40sss.pgh.pa.us

That confirms my recollection of multiple-day test runs, but doesn't
offer much more useful detail than that :-(. What I think I did
though was to create some large tables (much bigger than the RAM on
the machine I had) and actually measure the runtime of seq scans
versus full-table index scans, repeating plenty 'o times to try to
average out the noise. There was some talk in those threads of
reducing that to a publishable script, but it was never followed up
on.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuya Watari 2024-10-15 03:20:04 Re: [PoC] Reducing planning time when tables have many partitions
Previous Message px shi 2024-10-15 02:49:46 Re: a litter question about mdunlinkfiletag function