Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Who's "we"? AFAICS, CVS HEAD will treat a large copy the same as any
other large heapscan.
Umm, I'm talking about populating a table with COPY *FROM*. That's not a
heap scan at all.
No wonder we're failing to communicate. I assumed you were talking
about copy-to-file. Copy-from-file is going to be creating WAL entries
hence the no-checkpoint case doesn't apply anyway, no?
We are indeed having trouble to communicate :(.
No, I'm not talking about the new non-WAL-logged COPY optimization. COPY
FROM *would* create WAL entries, and the next checkpoint would clean
them. So far so good. But then you run VACUUM, as you often do after
loading a table, to set all hint bits. That will *not* generate WAL, and
next checkpoint is skipped.
To recap, the sequence is:
1. COPY FROM
2. checkpoint
3. VACUUM
Now you have buffer cache full of dirty buffers with usage_count=1, and
no WAL activity since last checkpoint. They will not be flushed until:
a) WAL activity happens and next checkpoint comes
b) database is shut down, or manual CHECKPOINT is issued
c) clock hand advances and decrements the usage_counts
It's a corner case. Probably not a problem in practice; you usually run
CREATE INDEX after loading a table, for example. But it exists.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
