From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Thom Brown <thom(at)linux(dot)com>, Rob Wultsch <wultsch(at)gmail(dot)com>, Joshua Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Advocacy <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: Unlogged vs. In-Memory |
Date: | 2011-05-05 17:30:24 |
Message-ID: | BANLkTinj-k3_gW73_0GRyJ4vUSGBhZyqrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
On Wed, May 4, 2011 at 4:19 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Well, the _init fork can go arbitrarily long without being used, so
>> you can't put any unfrozen tuples in there. There may be some game
>> that can be played here, but it's not simple, especially since the
>> heap and indices have to stay in sync.
>
> I don't think that's a sufficient response. It's clear that people
> expect unlogged tables would be used in conjunction with RAM disks,
> but they clearly don't work in that situation.
>
> That is exactly the main use case of "cache tables".
I think it's a bit harsh to say that they "don't work". As I
understand it, the use case that Rob is seeking here is the ability to
create a table space on a RAM disk and put unlogged tables (only) into
it and have everything continue to work after a reboot obliterates the
contents of the RAM disk. Fair enough - I can understand why that
would be useful, but I don't think we've ever promised anyone that
blowing away a tablespace was a safe operation. It might actually be
safe if only temporary tables are involved... assuming that the mount
point was the PG_<version>_<catversion> directory, rather than the
tablespace directory proper... but I doubt that we've ever documented
that anywhere, or promised that it would continue working in future
releases. It's a new idea to me, anyhow.
>> I actually think there is very little low-hanging fruit to be found in
>> terms of improving unlogged tables.
>
> Solving Rob's complaint seems very easy to me.
Maybe not. I think what you're proposing would essentially amount to
always storing the init forks in $PGDATA, even if the actual
tablespace is elsewhere. I agree that would solve Rob's problem, but
I'm not sure that it's the behavior that everyone wants in general.
>> The things that I didn't tackle
>> got skipped because they were really hard or low-value or had
>> significant downsides or all three.
>
>> We're not going to find a general
>> solution to this problem that is cheaper than WAL-logging everything;
>> that's why WAL-logging is basically the only form of crash-safety used
>> by any modern database product.
>
> That's not accurate. Many products provide a means to load bulk data
> without hitting the transaction log, without the need to truncate the
> table.
I agree that a bulk loading path that bypasses the WAL log is useful.
I'm not sure whether we want to try to grow unlogged tables into a
solution to that problem, or tackle it in some other way.
>> I think that the solution to the
>> problem of "I don't want to lose the whole table when the database
>> crashes" is going to involve partitioning - have a logged partition
>> and an unlogged partition, and periodically move stuff over. Even we
>> ultimately provide some automated way to have that happen under the
>> covers, I think that's still what it's going to be doing. I might be
>> all wet, of course, but that's what I think.
>
> That's very roughly what NOLOGGING hint does on an Oracle table, but
> without the partitioning.
How does that work?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-05-05 18:17:33 | Re: Unlogged vs. In-Memory |
Previous Message | Jeff Davis | 2011-05-05 17:20:56 | ubuntu software center |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-05-05 17:43:56 | Re: patch: fix race in SSI's CheckTargetForConflictsIn |
Previous Message | Bruce Momjian | 2011-05-05 17:28:50 | Re: Patch to improve style of generate_history.pl perl script |