Another documentation issue

On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

On the page https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-SEQ-PAGE-COST

it is only given the default value of this parameter.

No min/max values are provided..

The same can be sad about
https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-RANDOM-PAGE-COST

Sad. But you can interpret it as "there is no maximum". The actual maximum is DBL_MAX,
the biggest double precision value that your system can handle, and may depend on your
architecture.

However, this page
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
describes both default and mn/max, however t s says:

[quote]
The default is 1 on supported systems, otherwise 0
[/quote]]

No explanation of what is "supported system" is given...

And the same can be said about
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-IO-CONCURRENCY.

According to the source, it is "systems that have posix_fadvise()". We could document that,
but I don't know if it would help many people. I am not sure how easy and feasible it is
to research which versions of which operating systems qualify.

Yours,
Laurenz Albe

On 23 Apr 2025, at 09:16, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

However, this page
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
describes both default and mn/max, however t s says:

[quote]
The default is 1 on supported systems, otherwise 0
[/quote]]

No explanation of what is "supported system" is given...

And the same can be said about
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-IO-CONCURRENCY.

According to the source, it is "systems that have posix_fadvise()". We could document that,
but I don't know if it would help many people. I am not sure how easy and feasible it is
to research which versions of which operating systems qualify.

From memory it's supported on FreeBSD, NetBSD and Linux with Windows, macOS and
OpenBSD not supporting it. Assuming I'm not completely wrong (a 1 minute
search shows it's in the ballpark) we could perhaps add something like
"Unsupported platforms include (but isn't limited to) Windows and macOS" which
would provide a bit more clarity.

--
Daniel Gustafsson

On Tuesday, April 22, 2025, Igor Korot <ikorot01@gmail.com> wrote:

Hi, ALL,

On the page https://www.postgresql.org/docs/current/runtime-config-
query.html#GUC-SEQ-PAGE-COST

it is only given the default value of this parameter.

No min/max values are provided..

The same can be sad about
https://www.postgresql.org/docs/current/runtime-config-
query.html#GUC-RANDOM-PAGE-COST

Costs can’t be negative and no reasonable positive value is going to exceed
the data type limit, which is communicated via the data type specification.

David J.

Daniel Gustafsson <daniel@yesql.se> writes:

On 23 Apr 2025, at 09:16, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

No explanation of what is "supported system" is given...

According to the source, it is "systems that have posix_fadvise()". We could document that,
but I don't know if it would help many people. I am not sure how easy and feasible it is
to research which versions of which operating systems qualify.

From memory it's supported on FreeBSD, NetBSD and Linux with Windows, macOS and

OpenBSD not supporting it. Assuming I'm not completely wrong (a 1 minute
search shows it's in the ballpark) we could perhaps add something like
"Unsupported platforms include (but isn't limited to) Windows and macOS" which
would provide a bit more clarity.

If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?".

regards, tom lane

Hi, Tom,

On Wed, Apr 23, 2025 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

On 23 Apr 2025, at 09:16, Laurenz Albe <laurenz.albe@cybertec.at>

wrote:

On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

No explanation of what is "supported system" is given...

According to the source, it is "systems that have posix_fadvise()". We

could document that,

but I don't know if it would help many people. I am not sure how easy

and feasible it is

to research which versions of which operating systems qualify.

From memory it's supported on FreeBSD, NetBSD and Linux with Windows,

macOS and

OpenBSD not supporting it. Assuming I'm not completely wrong (a 1 minute
search shows it's in the ballpark) we could perhaps add something like
"Unsupported platforms include (but isn't limited to) Windows and macOS"

which

would provide a bit more clarity.

If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?

Imagine a person that wants to write a program which will cover creating
the table space.

Such person needs to cover the appropriate fields with possible values.

Is there a #define such person should check to cover the appropriate values?

Thank you?

".

Igor Korot <ikorot01@gmail.com> writes:

On Wed, Apr 23, 2025 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?

Imagine a person that wants to write a program which will cover creating
the table space.
Such person needs to cover the appropriate fields with possible values.
Is there a #define such person should check to cover the appropriate values?

HAVE_POSIX_FADVISE. Seems to me it'd be way easier to find that
from documentation that mentions posix_fadvise than from documentation
that says "it works on systems X, Y, Z".

regards, tom lane

Tom,

On Wed, Apr 23, 2025 at 1:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Igor Korot <ikorot01@gmail.com> writes:

On Wed, Apr 23, 2025 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?

Imagine a person that wants to write a program which will cover creating
the table space.
Such person needs to cover the appropriate fields with possible values.
Is there a #define such person should check to cover the appropriate

values?

HAVE_POSIX_FADVISE. Seems to me it'd be way easier to find that
from documentation that mentions posix_fadvise than from documentation
that says "it works on systems X, Y, Z".

Agreed.
Hopefully someone can put this in…

Thx.

Tom,

On Wed, Apr 23, 2025 at 1:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Igor Korot <ikorot01@gmail.com> writes:

On Wed, Apr 23, 2025 at 1:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?

Imagine a person that wants to write a program which will cover creating
the table space.
Such person needs to cover the appropriate fields with possible values.
Is there a #define such person should check to cover the appropriate values?

HAVE_POSIX_FADVISE. Seems to me it'd be way easier to find that
from documentation that mentions posix_fadvise than from documentation
that says "it works on systems X, Y, Z".

Most of the time the client and server are located on different machines.
So there is no way to identify what server is supporting.

How do you handle sch situation from the client POV?

Thank you.

On Wednesday, April 23, 2025, Igor Korot <ikorot01@gmail.com> wrote:

How do you handle sch situation from the client POV?

Get the current value. If it’s non-zero the system definitely supports
it. If it’s zero it probably doesn’t. But give the user an option to
specify a value anyway just in case. If they try and it errors, it doesn’t
support it.

David J.

Hi, Laurenz,

On Wed, Apr 23, 2025 at 2:16 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

On the page https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-SEQ-PAGE-COST

it is only given the default value of this parameter.

No min/max values are provided..

The same can be sad about
https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-RANDOM-PAGE-COST

Sad. But you can interpret it as "there is no maximum". The actual maximum is DBL_MAX,
the biggest double precision value that your system can handle, and may depend on your
architecture.

So if I want to execute it from the client code (whether ODBC based or
libpq based),
how do I handle it?

Because most of the time client and server are located on different machines...

Thank you.

Hi, David,

On Thu, Apr 24, 2025 at 12:23 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:

On Wednesday, April 23, 2025, Igor Korot <ikorot01@gmail.com> wrote:

How do you handle sch situation from the client POV?

Get the current value. If it’s non-zero the system definitely supports it. If it’s zero it probably doesn’t. But give the user an option to specify a value anyway just in case. If they try and it errors, it doesn’t support it.

There definitely is an option to set it.
The question is more about the default value...

Thank you.

On Wednesday, April 23, 2025, Igor Korot <ikorot01@gmail.com> wrote:

The question is more about the default value...

0 or 1, determined at server compilation time. You quoted the
documentation that says this…

David J.

On 23.04.25 11:14, Daniel Gustafsson wrote:

On 23 Apr 2025, at 09:16, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:

However, this page
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
describes both default and mn/max, however t s says:

[quote]
The default is 1 on supported systems, otherwise 0
[/quote]]

No explanation of what is "supported system" is given...

And the same can be said about
https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-IO-CONCURRENCY.

According to the source, it is "systems that have posix_fadvise()". We could document that,
but I don't know if it would help many people. I am not sure how easy and feasible it is
to research which versions of which operating systems qualify.

From memory it's supported on FreeBSD, NetBSD and Linux with Windows, macOS and
OpenBSD not supporting it. Assuming I'm not completely wrong (a 1 minute
search shows it's in the ballpark) we could perhaps add something like
"Unsupported platforms include (but isn't limited to) Windows and macOS" which
would provide a bit more clarity.

Note that PG18 supports prefetching on macOS without posix_fadvise(),
and we changed some of the documentation text to not mention
posix_fadvise() anymore. Also, some of the text and the defaults have
changed because of the async IO feature set. Maybe see if the text in
master provides the information you need.