RE: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1

On Wednesday, November 17, 2021 4:19 PM, Guillaume Lelarge guilla...@lelarge.info wrote: >> -> Parallel Seq Scan on c (cost=0.00..8591.67 rows=416667 width=0) (actual >> time=0.030..140.036 rows=33 loops=3) >In my previous example, actual row number is 33*

RE: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1

Wednesday, November 17, 2021 6:29 AM, nikolai.berkoff wrote: > > Parallel query is explained in > https://www.postgresql.org/docs/14/how-parallel-query-works.html and > https://www.postgresql.org/docs/14/parallel-plans.html > > The docs seem clear to me that as the nodes are executed in parallel

[Doc] Tiny fix for regression tests example

Hi When reading PG DOC, found some example code not correct as it said. https://www.postgresql.org/docs/devel/regress-run.html Here's a tiny fix in regress.sgml. -make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB" +make check PGOPTIONS="-c geqo=off -c work_mem=50MB" log_che

RE: doc: Document how to run regression tests with custom server settings

On Wednesday, June 30, 2021 11:15 AM, Craig Ringer craig.rin...@2ndquadrant.com wrote >Yes, that'd make a lot of sense. > >PGOPTIONS is more suited for client settings. > >Willing to cook up a quick patch? Thanks for replying. Here is my patch to fix the doc

RE: doc: Document how to run regression tests with custom server settings

Hi I was doing regression testing according to the PG-doc at [1]. The modification at 854434c5 seems not correct, could you please take a check at it? >make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB" The above command reported an error like this: failed: FATAL: parameter "log_c

RE: pg_type_d.h location incorrect

On Thursday, May 27, 2021 11:27 PM, Tom Lane wrote >No ... "patch -p1 <~/improve-pgservice-docs.patch" works fine for me. Oh, never tried "patch -p1" command before but it worked. Thanks!! BTW, here is my previous operation to apply your patch(failed, which is strange IMO) $ git apply --3way im

RE: pg_type_d.h location incorrect

On Thursday, May 27, 2021 10:58 AM, Tom Lane wrote >So I ended up with the attached --- what do you think? The doc-fix LGTM. But I couldn't apply the patch at HEAD(2941138e60). Maybe you did the fix at a branch other than HEAD? >Also, looking at this, I note that "~/.pg_service.conf" is still

RE: pg_type_d.h location incorrect

On Wednesday, May 26, 2021 12:20 PM, Tom Lane wrote >In the first place, it's somewhere between unhelpful and flat out wrong for >people on Windows, where the backtick notation doesn't work (AFAIK). >In the second, it will distract almost every user, who will need >to stop for a second or two to t

RE: pg_type_d.h location incorrect

Hi Attached a patch to fix the incorrect location description of pg_type_d.h posted by myself at [1]. [1] https://www.postgresql.org/message-id/162149020918.26174.7150424047314144...@wrigleys.postgresql.org Regards, Tang 0001-dir-fix-for-pg_type_d.h.patch Description: 0001-dir-fix-for-pg_typ

RE: typo in doc for "Miscellaneous Coding Conventions"

>"were not" is typical usage when stating a contrary-to-fact hypothetical. > If the implementation (or you) didn’t do X, then Y bad thing could happen. Really thanks for your kindly reply and explain. Please forgive me for my poor English. Anyway, got it. Regards, Tang

doc-fix-for-POSIX-Time-Zone-Specifications

Hi Attached a patch to delete "CURRENT(as of 2020) " description in POSIX Time Zone Specifications. I'm not a native English speaker, if my fix is not appropriate or insufficient, please be kind to share your thought with me. Regards, Tang 0001-doc-fix-for-POSIX-Time-Zone-Specifications.patch

RE: [DOC] pg_stat_replication_slots representation style inconsisitant

On Tuesday, May 11, 2021 2:42 PM, Michael Paquier wrote: >I was looking at this thread, and please note that there is no need to >do anything here as the WAL prefetch has been reverted for now as of >c2dc1934. Thanks for the updating. Got it. Regards, Tang

RE: Unsupported version mentioned at Using EXPLAIN

Tom Lane wrote: > On 2021-May-07, Alvaro Herrera wrote: >> I think there's more to this than just changing or removing the version >> number; a better approach might be to update the documentation so that >> it matches what current versions do. >Yeah. The reason why a specific version is mentio

Unsupported version mentioned at Using EXPLAIN

Hi When referring Doc, found one place mentioned "using 9.3 development sources." at [1]. Which I think 9.3 means PG9.3 [1] https://www.postgresql.org/docs/current/using-explain.html It seems to show up since PG9.2 and changed to 9.3 at PG9.3. However, since 9.3 nobody updates the version anym

RE: [DOC] pg_stat_prefetch_recovery representation style inconsisitant

Sorry, wrong title name. I fixed the view representation of "pg_stat_prefetch_recovery". Fix it. Regards, Tang

RE: [DOC] pg_stat_replication_slots representation style inconsisitant

On Friday, April 30, 2021 12:38 PM, Hou, Zhijie/侯 志杰 wrote >I noticed one more thing. >It seems the column " stats_reset | timestamp with time zone " is not >listed in the pg_stat_prefetch_recovery view. >Should we add this column too ? Indeed, column added. Thanks. Regards, Tang 0001-p

[DOC] pg_stat_replication_slots representation style inconsisitant

Hi When reading the manual doc, I found an inconsistent representation style for the newly added pg_stat_prefetch_recovery view in PG14 at [1]. Same problem seems to be reported by Noriyoshi Shinoda who also proposed a patch to fix the problem at[2]. I tried to fix the problem in a way differen