| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Kenneth Marshall <ktm(at)rice(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, marcin mank <marcin(dot)mank(at)gmail(dot)com>, Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: unlogged tables |
| Date: | 2010-11-17 19:42:43 |
| Message-ID: | 4CE43033.2080008@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Now, a few minutes ago Robert was muttering about supporting more than
> one kind of degraded-reliability table. I could see inventing
> "unlogged" tables, which means exactly that (no xlog support, but we
> still checkpoint/fsync as usual), and "unsynced" tables which
> also/instead suppress fsync activity. The former type could be assumed
> to survive a clean shutdown/restart, while the latter wouldn't. This
> would let people pick their poison.
We're assuming here that the checkpoint activity for the unlogged table
causes significant load on a production system. Maybe we should do some
testing before we try to make this overly complex? I wouldn't be
surprised to find that on most filesystems the extra checkpointing of
the unlogged tables adds only small minority overhead.
Shouldn't be hard to build out pgbench into something which will test
this ... if only I had a suitable test machine available.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-17 19:44:27 | Re: unlogged tables |
| Previous Message | Tom Lane | 2010-11-17 19:37:30 | Re: unlogged tables |