Re: pg_basebackup vs. Windows and tablespaces
| От | Amit Kapila |
|---|---|
| Тема | Re: pg_basebackup vs. Windows and tablespaces |
| Дата | |
| Msg-id | CAA4eK1J4jdVeC-HRtXGue80e17LRMDD4Fg9SQY2_ndX0ZhNbSg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_basebackup vs. Windows and tablespaces (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: pg_basebackup vs. Windows and tablespaces
|
| Список | pgsql-hackers |
On Fri, Nov 14, 2014 at 9:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 10:37 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >>
> >
> > I have mentioned that this can be usable for Linux users as well on that
> > thread, however I think we might want to provide it with an option for
> > linux users. In general, I think it is good to have this patch for Windows
> > users and later if we find that Linux users can also get the benefit with
> > this functionality, we can expose the same with an additional option.
>
> Why make it an option instead of just always doing it this way?
>
To avoid extra work during archive recovery if it is not required. I
> On Thu, Nov 13, 2014 at 10:37 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >>
> >
> > I have mentioned that this can be usable for Linux users as well on that
> > thread, however I think we might want to provide it with an option for
> > linux users. In general, I think it is good to have this patch for Windows
> > users and later if we find that Linux users can also get the benefit with
> > this functionality, we can expose the same with an additional option.
>
> Why make it an option instead of just always doing it this way?
>
To avoid extra work during archive recovery if it is not required. I
understand that this might not create any measurable difference, but
still there is addition I/O involved (read from file) which can be avoided.
OTOH, if that is okay, then I think we can avoid few #ifdef WIN32 that
this patch introduces and can have consistency for this operation on
both linux and Windows.
В списке pgsql-hackers по дате отправления: