| 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: | Whole Thread | Raw Message | 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 |