Re: Ambiguous description on new columns
Hi, Le mar. 21 mai 2024 à 12:40, PG Doc comments form a écrit : > The following documentation comment has been logged on the website: > > Page: > https://www.postgresql.org/docs/16/logical-replication-col-lists.html > Description: > > The documentation on this page mentions: > > "If no column list is specified, any columns added later are automatically > replicated." > > It feels ambiguous what this could mean. Does it mean: > > 1/ That if you alter the table on the publisher and add a new column, it > will be replicated > > 2/ If you add a column list later and add a column to it, it will be > replicated > > In both cases, does the subscriber automatically create this column if it > wasn't there before? I recall reading that the initial data synchronization > requires the schema of the publisher database to be created on the > subscriber first. But then later updates sync newly created columns? I > don't > recall any pages on logical replication mentioning this, up to this point. > > It feels ambiguous. DDL commands are not replicated, so the new columns don't appear automagically on the subscriber. You have to add them to the subscriber. But values of new columns are replicated, whether or not you have added the new columns on the subscriber. Regards. -- Guillaume.
Doc fix
Hey, While translating the new minor release docs, I've found an issue. Patch attached fixes this issue. The issue is only available on v11 and v12. Patch made on v11, but should also work on v12. Thanks. Regards. -- Guillaume. diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 87e2a91da5..d8b20844a9 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -2641,7 +2641,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i n_tup_upd bigint Number of rows updated (includes HOT updated rows updated rows) + linkend="storage-hot">HOT updated rows) n_tup_del
Re: DocBook 5.2
Le lun. 5 sept. 2022 à 13:14, Alvaro Herrera a écrit : > On 2022-Sep-05, Jürgen Purtz wrote: > > > - > > + > >User-Defined Types > > OK, these seem quite significant changes that are likely to cause great > pain. So I repeat my question, what are the benefits of making this > change? They better be very very substantial. > I totally agree with Alvaro. They will also cause massive pain for translators. There are already some changes that were pretty bad for me. For example, when all the tables in func.sgml were modified. In v15, I also remember massive changes on protocol.sgml. I won't complain if there is a significant benefit for readers, which is why I didn't complain for func.sgml even if it meant I had to translate it all over again. But if there's a massive change over the whole manual for a strictly limited benefit, I guess there won't be enough motivation for me to translate it all over again. -- Guillaume.
Re: TABLESPACE
Le dim. 4 sept. 2022, 10:19, PG Doc comments form
a écrit :
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/sql-createtablespace.html
> Description:
>
> When exporting a table create script pgAdmin includes a command "TABLESPACE
> pg_default;" such as below
>
> CREATE TABLE IF NOT EXISTS "DbTest"."Test"
> (
> "TestID" integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT 1
> START 1 MINVALUE 1 MAXVALUE 2147483647 CACHE 1 ),
> "TestName" character varying(80) COLLATE pg_catalog."default" NOT
> NULL,
> "CreateTimestamp" timestamp without time zone NOT NULL DEFAULT
> LOCALTIMESTAMP,
> "UpdateTimestamp" timestamp without time zone NOT NULL DEFAULT
> LOCALTIMESTAMP,
> CONSTRAINT "Test_pk" PRIMARY KEY ("TestID"),
> )
>
> TABLESPACE pg_default;
>
As you can see, there's no ";" between ")" and "TABLESPACE", so it's not a
command on its own but another clause of the CREATE TABLE statement. It
indicates the tablespace for the new table.
Re: Didn't correct output for LTRIM function
Le lun. 13 juin 2022 à 10:06, PG Doc comments form
a écrit :
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/bug-reporting.html
> Description:
>
> First check the output of "select LTRIM(' startech academy ', ' sta');"
>
> output is "rtech academy "
> now the thing is output of "select LTRIM(' startech academy ', '
> star');"
>output is "ech academy "
> the question is where is 't'?
>
>
It's trimmed, because you asked t to be removed. It trims every single
character at the beginning of the string till it encounters another
character. The doc example makes it more clear:
ltrim('zzzytest', 'xyz') → test
https://www.postgresql.org/docs/14/functions-string.html
The problem is when we do LTRIM for trimming the first four characters, it
> trims the first five characters. but in the case of doing three characters,
> it gives the correct output.
>
Both outputs are correct actually.
--
Guillaume.
Re: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1
Hi, Le mer. 17 nov. 2021 à 06:32, tanghy.f...@fujitsu.com < tanghy.f...@fujitsu.com> a écrit : > Wednesday, November 17, 2021 6:29 AM, nikolai.berkoff < > nikolai.berk...@pm.me> 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 > then the > > time execution time is not 140.036*3. The 140.036 value is actual time > the Parallel > > Seq Scan nodes ran for but there were up to 2 running in parallel. > > Thanks for your reply. > I read your references but still confused about the 'loops' in parallel > query result. > > > -> 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*3=1e6(which is > correct), so I think the actual time is 140.036*3ms. > Do your think the loops(3) has no meaning for parallel scan node when > calculate actual time? > > As far as I understand it, you have to multiply the number of rows by the number of loops, but this doesn't apply to duration at least for parallel queries. -- Guillaume.
