Re: Performance and WAL on big inserts/updates

Поиск
Список
Период
Сортировка
От Sailesh Krishnamurthy
Тема Re: Performance and WAL on big inserts/updates
Дата
Msg-id mjqwu5qn43n.fsf@cs.berkeley.edu
обсуждение исходный текст
Ответ на Re: Performance and WAL on big inserts/updates  (Marty Scholes <marty@outputservices.com>)
Ответы Re: Performance and WAL on big inserts/updates  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
(Just a note: my comments are not pg-specific .. indeed I don't know
much about pg recovery).

>>>>> "Marty" == Marty Scholes <marty@outputservices.com> writes:
   Marty> If the DB state cannot be put back to a consistent state   Marty> prior to a SQL statement in the log, then
NOamount of   Marty> logging will help.  The idea is that the state can be put   Marty> back to what it was prior to a
particularlog entry, be it   Marty> raw datafile blocks or a SQL statement.
 

The point is that with redo logging, you can just blindly apply the
log to the data pages in question, without even really restarting the
database.

Note that in ARIES, recovery follows: (1) analysis, (2) redo
_everything_ since last checkpoint, (3) undo losers. 

So logging carefully will indeed help get the system to a consistent
state - actually after phase (2) above the system will be in precisely
the state during the crash .. and all that's left to do is undo all
the live transactions (losers). 

BTW, logging raw datafile blocks would be pretty gross (physical
logging) and so ARIES logs the changes to each tuple in "logical"
fashion .. so if only one column changes only that value (before and
after images) are logged. This is what's called "physiological
logging".
   Marty> See above.  If this cannot be resolved prior to   Marty> re-executing a statement in the log, then the
problemis   Marty> beyond ANY subsequent logging.
 

Not true ! By applying the log entries carefully you should be able to
restore the system to a consistent state. 
   >> Having said that, page-oriented undo logging can be a pain when   >> B-tree pages split. For higher concurrency,
ARIESuses logical   >> undo logging. In this case, the logs are akin to your "parsed   >> statement" idea.   >> 
 
   Marty> Yes, my experience exactly.  Maybe we are the only company   Marty> on the planet that experiences this sort
ofthing.  Maybe
 

Well, logical undo is still at a much lower level than parsed
statements. Each logical undo log is something like "delete key 5 from
index xyz". 
   Marty> Maybe this is not a "traditional" RDBMS app, but I am not   Marty> in the mood to write my own storage
infrastructurefor it.
 

I agree that your app has a lot of updates .. it's just that I'm not
convinced that logical logging is a clean solution. 

I also don't have a solution for your problem :-)

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Glaesemann
Дата:
Сообщение: Re: The Name Game: postgresql.net vs. pgfoundry.org
Следующее
От: Marty Scholes
Дата:
Сообщение: Re: Performance and WAL on big inserts/updates