Re: pg_dump additional options for performance
От | Gregory Stark |
---|---|
Тема | Re: pg_dump additional options for performance |
Дата | |
Msg-id | 871w6jgxvd.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: pg_dump additional options for performance (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
"Bruce Momjian" <bruce@momjian.us> writes: > Decibel! wrote: >> On Feb 26, 2008, at 4:36 PM, Tom Lane wrote: >> > I think a sane way to think about what Simon would like to accomplish >> > is not "turn psql into a parallel job scheduler" >> >> >> My $0.02: I often find myself wishing I could perform parallel >> operations in psql. There was a proposal for that that came up during >> 8.3 development; whatever happened to it? > > The concurrent psql patch was never updated to an acceptable state for > it to be reviewed. Well, I got tied in knots trying to fix up the SIGINT handling working properly. I want to try rewriting it from scratch to try to produce a cleaner version. But that doesn't mean nobody should look at the patch and give comments. It would be silly for me to rewrite it keeping things basically the way they are now just cleaned up -- only to then find out that people disagree with the basic approach and don't accept it anyways. This may be a trivial example but some pretty major patches which required a lot of work have been submitted before where nobody read any of the WIP patches and then basic questions were raised long after a lot of work had been committed. We seem to often think of "review" as equivalent to "commit". But patch authors often want to get some confirmation they're on the right track before they move on the next step. As a result many patches kind of get stuck in a catch-22 where they're not ready for review and no ready for development either. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
В списке pgsql-hackers по дате отправления: