From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Enno Wein <ennowein(at)yahoo(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15115: temporary AND unlogged tables for parallel db import |
Date: | 2018-03-16 15:25:03 |
Message-ID: | 27167.1521213903@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Enno" == Enno Wein <ennowein(at)yahoo(dot)com> writes:
> Enno> However, it doesn't seem to work like that. Even with ONLY either
> Enno> unlogged (the global ones) and temprorary tables (the local ones), the
> Enno> system still produces a huge amount of WAL/checkpoint writes.
> So what you just said above is that you get a lot of WAL/checkpoint
> writes when using unlogged non-temporary tables. What this implies is
> that you have something _else_ going on, involving persistent tables
> (i.e. non-temporary non-unlogged tables - these are the only kind that
> get their data changes WAL-logged).
One theory is that the OP's workload involves a huge number of short-lived
temp tables, and then the WAL traffic is coming from the system catalog
changes involved in creating/dropping those tables (since even a temp
table must have entries in pg_class, pg_attribute, etc). That's only
a theory though, given the lack of any hard evidence in this thread.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2018-03-16 15:34:48 | BUG #15116: pg_recvlogical always fails |
Previous Message | Stephen Frost | 2018-03-16 14:56:42 | Re: BUG #15115: temporary AND unlogged tables for parallel db import |