From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Schema version management |
Date: | 2012-05-21 20:30:39 |
Message-ID: | CAAZKuFYpkzRM5XEibmq=pnk7BUNnBOeCVgQt_y4Y5yWuvL=VqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 20, 2012 at 9:03 PM, Joel Jacobson <joel(at)trustly(dot)com> wrote:
> On Mon, May 21, 2012 at 10:06 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>> Also, now that I look more carefully, there was a lot of conversation
>> about this patch; it seems like what you are doing now is reporting
>> its successful use, and I did not understand that by reading the
>> abstract of your email. And, beyond that, do we have a summary of the
>> open questions that prevented it from being committed?
>
> Good idea. Here is an attempt to a summary:
Thank you, that's very informative. I'd like to reiterate one
question, though, which is something like:
"How do you feel that the since-committed directory-output/input
support in pg_dump/pg_restore could or should influence your patch, if
at all?"
It seems like now that there is support for spitting out a bunch of
files in a directory for pg_dump that is now going to be supported for
a long time that a new feature like yours might be more cohesive if it
somehow played with that. I must confess I haven't read the patch in
detail, especially if it has been updated, but back then there was no
multi-file output mode from pg_dump, and now there is one. My naive
understanding is this would be adding a second one as-is, but I wonder
if that is strictly necessary to fulfill the use case.
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-05-21 20:37:06 | Re: Why is indexonlyscan so darned slow? |
Previous Message | Jeff Janes | 2012-05-21 20:30:37 | Re: Why is indexonlyscan so darned slow? |