Thread: Another documentation issue
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 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. Thank you
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?
".
regards, tom lane
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.
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". 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. > > regards, tom lane
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. > > > 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
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 givethe 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. > > David J.
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.