Re: BUG #15115: temporary AND unlogged tables for parallel db import

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

In response to

Responses

Browse pgsql-bugs by date

  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