Re: why select count(*) consumes wal logs - Mailing list pgsql-general

From Bruno Lavoie
Subject Re: why select count(*) consumes wal logs
Date
Msg-id CAD+GXYOczcCYKk=6cst5Zn5d8Ew_fYnDtf-kyam6y0qmLE60Mw@mail.gmail.com
Whole thread Raw
In response to Re: why select count(*) consumes wal logs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: why select count(*) consumes wal logs
List pgsql-general


Le mar. 6 nov. 2018 12:40 PM, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
Ravi Krishna <srkrishna1@aol.com> 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 than 10min and still running. Intrigued, I checked locks and saw nothing.  Then I noticed something
> strange.  When select count(*) runs, PG is writing to wal_logs, and that too a large amount. Why? 

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.

                        regards, tom lane


And IIRC, it can generate a high WAL traffic since the first page change after a checkpoint is done with full page write. And you said that it's happening on a big table with wide rows....

pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: Idle query that's not ""?
Next
From: David Gauthier
Date:
Subject: recursion in plpgsql