Re: directory archive format for pg_dump

Поиск
Список
Период
Сортировка
От José Arthur Benetasso Villanova
Тема Re: directory archive format for pg_dump
Дата
Msg-id AANLkTi=AEi3F6jC0Zy3dG9njiwJJC8Y6V090-hMonyyn@mail.gmail.com
обсуждение исходный текст
Ответ на directory archive format for pg_dump  (Joachim Wieland <joe@mcknight.de>)
Ответы Re: directory archive format for pg_dump  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: directory archive format for pg_dump  (Joachim Wieland <joe@mcknight.de>)
Список pgsql-hackers
Hi Dimitri and Joachim.

I've looked the patch too, and I want to share some thoughts too. I've
used http://wiki.postgresql.org/wiki/Reviewing_a_Patch to guide my
review.

Submission review:

I've apllied and compiled the patch successfully using the current master.

Usability review:

The dir format generated in my database 60 files, with different
sizes, and it looks very confusing. Is it possible to use the same
trick as pigz and pbzip2, creating a concatenated file of streams?

Feature test:

Just a partial review. I can dump / restore using lzf, but didnt
stress it hard to check robustness.

Performance review:

Didnt test it hard too, but looks ok.


Coding review:

Just a shallow review here.

>> I think I'd like to see a separate patch for the new compression
>> support. Sorry about that, I realize that's extra work…

Same feeling here, this is the 1st thing that I notice.

The md5.c and kwlookup.c reuse using a link doesn't look nice either.
This way you need to compile twice, among others things, but I think
that its temporary, right?

--
José Arthur Benetasso Villanova


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Changes to Linux OOM killer in 2.6.36