Re: NOLOGGING option, or ?
От | Simon Riggs |
---|---|
Тема | Re: NOLOGGING option, or ? |
Дата | |
Msg-id | 1117658004.3844.1059.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: NOLOGGING option, or ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 2005-06-01 at 14:14 -0400, Tom Lane wrote: > So what I'm thinking is we need no special WAL entries for this. What > we need is just an operating mode of COPY in which it doesn't WAL-log > its inserts, but instead fsyncs before completion, much like index build > does. For safety it must do all its inserts into freshly-added pages; > this is not to ensure truncatability, because we aren't going to do that > anyway, but to ensure that we don't have unlogged operations changing > pages that might contain committed tuples. (That would pose a risk of > losing committed data to incomplete writes in case of system crash > partway through. The same reason is why we need exclusive lock: else > we might end up with pages containing a mix of logged and unlogged > tuples.) Also there can be no indexes, since we don't want index > entries pointing to unlogged tuples. And PITR can't be enabled. > Otherwise no problem. What you describe above is a coherent set of features that provide most of the benefits I sought, plus some others. We also don't mess with WAL, which is grand thing. We gain the ability to load into tables with rows already in them. I don't agree with all of your other points, but given time schedules, I think that we win with the above, so forget the rest. The main COPY/LOAD DATA discussion is on another thread of this from Alon, who has some interesting ideas and some really cool performance results to share. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: