Re: Proposing pg_hibernate
| От | Amit Kapila |
|---|---|
| Тема | Re: Proposing pg_hibernate |
| Дата | |
| Msg-id | CAA4eK1L7KmCaf_9wOoK2bYj4V4hNs53aTxqc9sC-qS7JuXmhPw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposing pg_hibernate (Gurjeet Singh <gurjeet@singh.im>) |
| Ответы |
Re: Proposing pg_hibernate
Re: Proposing pg_hibernate |
| Список | pgsql-hackers |
On Wed, May 28, 2014 at 5:30 PM, Gurjeet Singh <gurjeet@singh.im> wrote:
> On Wed, May 28, 2014 at 2:15 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > How about the cases when shared buffers already contain some
> > data:
> > a. Before Readers start filling shared buffers, if this cluster wishes
> > to join replication as a slave and receive the data from master, then
> > this utility might need to evict some buffers filled during startup
> > phase.
>
> A cluster that wishes to be a replication standby, it would do so
> while it's in startup phase. The BlockReaders are launched immediately
> on cluster reaching consistent state, at which point, I presume, in
> most of the cases, most of the buffers would be unoccupied.
> On Wed, May 28, 2014 at 2:15 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > How about the cases when shared buffers already contain some
> > data:
> > a. Before Readers start filling shared buffers, if this cluster wishes
> > to join replication as a slave and receive the data from master, then
> > this utility might need to evict some buffers filled during startup
> > phase.
>
> A cluster that wishes to be a replication standby, it would do so
> while it's in startup phase. The BlockReaders are launched immediately
> on cluster reaching consistent state, at which point, I presume, in
> most of the cases, most of the buffers would be unoccupied.
Even to reach consistent state, it might need to get the records
from master (example to get to STANDBY_SNAPSHOT_READY state).
> Hence
> BlockReaders might evict the occupied buffers, which may be a small
> fraction of total shared_buffers.
Yes, but I think still it depends on how much redo replay happens
> BlockReaders might evict the occupied buffers, which may be a small
> fraction of total shared_buffers.
Yes, but I think still it depends on how much redo replay happens
on different pages.
> > b. As soon as the server completes startup (reached consistent
> > point), it allows new connections which can also use some shared
> > buffers before Reader process could use shared buffers or are you
> > planing to change the time when users can connect to database.
>
> The BlockReaders are launched immediately after the cluster reaches
> consistent state, that is, just about when it is ready to accept
> connections. So yes, there is a possibility that the I/O caused by the
> BlockReaders may affect the performance of queries executed right at
> cluster startup. But given that the performance of those queries was
> anyway going to be low (because of empty shared buffers), and that
> BlockReaders tend to cause sequential reads, and that by default
> there's only one BlockReader active at a time, I think this won't be a
> concern in most of the cases. By the time the shared buffers start
> getting filled up, the buffer replacement strategy will evict any
> buffers populated by BlockReaders if they are not used by the normal
> queries.
> > b. As soon as the server completes startup (reached consistent
> > point), it allows new connections which can also use some shared
> > buffers before Reader process could use shared buffers or are you
> > planing to change the time when users can connect to database.
>
> The BlockReaders are launched immediately after the cluster reaches
> consistent state, that is, just about when it is ready to accept
> connections. So yes, there is a possibility that the I/O caused by the
> BlockReaders may affect the performance of queries executed right at
> cluster startup. But given that the performance of those queries was
> anyway going to be low (because of empty shared buffers), and that
> BlockReaders tend to cause sequential reads, and that by default
> there's only one BlockReader active at a time, I think this won't be a
> concern in most of the cases. By the time the shared buffers start
> getting filled up, the buffer replacement strategy will evict any
> buffers populated by BlockReaders if they are not used by the normal
> queries.
Even Block Readers might need to evict buffers filled by user
queries or by itself in which case there is chance of contention, but
again all these are quite rare scenario's.
> > I am not sure if replacing shared buffer contents in such cases can
> > always be considered useful.
>
> IMHO, all of these caveats, would affect a very small fraction of
> use-cases and are eclipsed by the benefits this extension provides in
> normal cases.
> > I am not sure if replacing shared buffer contents in such cases can
> > always be considered useful.
>
> IMHO, all of these caveats, would affect a very small fraction of
> use-cases and are eclipsed by the benefits this extension provides in
> normal cases.
I agree with you that there are only few corner cases where evicting
shared buffers by this utility would harm, but was wondering if we could
even save those, say if it would only use available free buffers. I think
currently there is no such interface and inventing a new interface for this
case doesn't seem to reasonable unless we see any other use case of
such a interface.
В списке pgsql-hackers по дате отправления: