Re: why select count(*) consumes wal logs

Ravi Krishna schrieb am 07.11.2018 um 15:10: > >> select data_page_checksum_version from pg_control_init() > > returned 1. So we have page_checksum turned on, and wal_log_hints off. If page_checksum is enabled, then wal_log_hints is ignored (or actually always assumed "on")

Re: why select count(*) consumes wal logs

> select data_page_checksum_version from pg_control_init() returned 1. So we have page_checksum turned on, and wal_log_hints off.

RE: why select count(*) consumes wal logs

> How to find out which parameter were used with initdb pg_controldata -D | grep sum ...should give you something like: Data page checksum version: 0 ...and 0 means off. Similarly, from SQL: select data_page_checksum_version from pg_control_init() Steve. This email is confidential.

Re: why select count(*) consumes wal logs

> As long as you don’t have page checksums turned on, > you can prevent this by turning off wal_log_hints.   I did not run initdb. How to find out which parameter were used with initdb. For page checksums to be on, it must have been run with -k option. Our wal_log_hints is left at default

RE: why select count(*) consumes wal logs

As long as you don’t have page checksums turned on, you can prevent this by turning off wal_log_hints. Steve. This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cant

Re: why select count(*) consumes wal logs

Le mar. 6 nov. 2018 12:40 PM, Tom Lane a écrit : > Ravi Krishna writes: > > I loaded 133 million rows to a wide table (more than 100 cols) via COPY. > The table has > > no index at this time. Since I am the only user I don't see any other > activity. > > Now when I run select count(*) on the tab

Re: why select count(*) consumes wal logs

Michael Nolan writes: > On Tue, Nov 6, 2018 at 11:40 AM Tom Lane wrote: >> That represents setting the yes-this-row-is-committed hint bits on the >> newly loaded rows. The first access to any such row will set that bit, >> whether it's a select or a VACUUM or whatever. > Tom, does that include

Re: why select count(*) consumes wal logs

On Tue, Nov 6, 2018 at 11:40 AM Tom Lane wrote: > > That represents setting the yes-this-row-is-committed hint bits on the > newly loaded rows. The first access to any such row will set that bit, > whether it's a select or a VACUUM or whatever. > > Tom, does that include ANALYZE? -- Mike Nolan

Re: why select count(*) consumes wal logs

>That represents setting the yes-this-row-is-committed hint bits on the >newly loaded rows.  The first access to any such row will set that bit, >whether it's a select or a VACUUM or whatever. yes now I recollect reading this in a blog. Thanks Tom.

Re: why select count(*) consumes wal logs

Ravi Krishna writes: > I loaded 133 million rows to a wide table (more than 100 cols) via COPY. The > table has > no index at this time. Since I am the only user I don't see any other > activity. > Now when I run select count(*) on the table where I just loaded data, it runs > for ever, > more

RE: why select count(*) consumes wal logs

I concord. Why VACUUM when there is no update or deletes. Regards, Virendra From: Ron [mailto:ronljohnso...@gmail.com] Sent: Tuesday, November 06, 2018 12:20 PM To: pgsql-general@lists.postgresql.org Subject: Re: why select count(*) consumes wal logs On 11/06/2018 11:12 AM, Michael Nolan wrote

Re: why select count(*) consumes wal logs

On 11/06/2018 11:12 AM, Michael Nolan wrote: On Tue, Nov 6, 2018 at 11:08 AM Ravi Krishna > wrote: PG 10.5 I loaded 133 million rows to a wide table (more than 100 cols) via COPY. It's always a good idea after doing a large scale data load to do a vacuum an

Re: why select count(*) consumes wal logs

Must be something to do with Vaccum as the second time I ran the SQL, it did not consume WAL logs.

Re: why select count(*) consumes wal logs

On Tue, Nov 6, 2018 at 11:08 AM Ravi Krishna wrote: > PG 10.5 > > I loaded 133 million rows to a wide table (more than 100 cols) via COPY. > It's always a good idea after doing a large scale data load to do a vacuum analyze on the table (or the entire database.) -- Mike Nolan