On Thu, 2008-10-30 at 09:46 +0900, Koichi Suzuki wrote:
> I'm not sure if blocks reffered from all WAL records in single WAL
> segment can fit kernel cache. This is why current pg_readahead
> returns the last LSN and require starting LSN. So far, with FPW, it
> seems that we can prefetch all
Hi,
2008/10/29 Simon Riggs <[EMAIL PROTECTED]>:
>
> On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
>
>> 1. You should avoid useless posix_fadvise() calls. In the naive
>> implementation, where you simply call posix_fadvise() for every page
>> referenced in every WAL record, you'll d
I'm not sure if blocks reffered from all WAL records in single WAL
segment can fit kernel cache. This is why current pg_readahead
returns the last LSN and require starting LSN. So far, with FPW, it
seems that we can prefetch all the pages in a WAL segment. So it
will be okay for archive log c
On Wed, 2008-10-29 at 09:55 +0900, Koichi Suzuki wrote:
> I'd like to hear some more about these. I'm more than happy to write
> all the code inside PG core to avoid overhead to create another
> process.
Having an external program can help earlier releases also, so I think
this is the right ap
On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
> 1. You should avoid useless posix_fadvise() calls. In the naive
> implementation, where you simply call posix_fadvise() for every page
> referenced in every WAL record, you'll do 1-2 posix_fadvise() syscalls
> per WAL record, and t
Heikki,
1. In the code, all the referenced page is extracted from the WAL
records in scope and sorted to schedule and avoid double
posix_fadvise() calls.If full page write is included as the first
WAL record, such page is not prefetched.Although there's still
some risk to call posix_fadvis
Hi,
> I think we would have to maintain two pointers one for the prefetch and one
> for the actual running. But the logic in for recovery is complex enough that
> I'm concerned about changing it enough to do that and whether it can be done
> without uglifying the code quite a bit.
Yes, this is wh
Thanks for a lot of inspiring discussions.
Please note that my proposal includes only a few lines of change to
the recovery code itself. It does not affect buffer management,
order of WAL record applying etc. Only change needed is to invoke
prefetch feature if redo is going to read WAL which h
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 17:40 -0400, Bruce Momjian wrote:
>> Gregory Stark wrote:
>> > Simon Riggs <[EMAIL PROTECTED]> writes:
>> >
>> > > I'm happy with the idea of a readahead process. I thought we were
>> > > implementing a BackgroundReader process for o
On Tue, 2008-10-28 at 17:40 -0400, Bruce Momjian wrote:
> Gregory Stark wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >
> > > I'm happy with the idea of a readahead process. I thought we were
> > > implementing a BackgroundReader process for other uses. Is that dead
> > > now?
> >
> > You
Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I'm happy with the idea of a readahead process. I thought we were
> > implementing a BackgroundReader process for other uses. Is that dead
> > now?
>
> You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 12:34 +, Gregory Stark wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>
>> I've never liked it -- I
>> always hated that in Oracle and thought it was a terrible kludge.
>
> But now... If you have a better way, great, but that
On Tue, 2008-10-28 at 12:34 +, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I'm happy with the idea of a readahead process. I thought we were
> > implementing a BackgroundReader process for other uses. Is that dead
> > now?
>
> You and Bruce seem to keep resurrecting
Gregory Stark wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
And are people running raid arrays not likely to be
running modern OSes anyways?
No and those that are can upgrade.
Joshua D. Drake
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Gregory Stark wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
I'm happy with the idea of a readahead process. I thought we were
implementing a BackgroundReader process for other uses. Is that dead
now?
You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
always hated tha
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm happy with the idea of a readahead process. I thought we were
> implementing a BackgroundReader process for other uses. Is that dead
> now?
You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
always hated that in Oracle and tho
Gregory Stark wrote:
"Koichi Suzuki" <[EMAIL PROTECTED]> writes:
This is my first proposal of PITR performance improvement for
PostgreSQL 8.4 development. This proposal includes readahead
mechanism of data pages which will be read by redo() routines in the
recovery. This is especially effec
On Tue, 2008-10-28 at 16:33 +0900, Koichi Suzuki wrote:
> This is my first proposal of PITR performance improvement for
> PostgreSQL 8.4 development. This proposal includes readahead
> mechanism of data pages which will be read by redo() routines in the
> recovery. This is especially effectiv
"Koichi Suzuki" <[EMAIL PROTECTED]> writes:
> This is my first proposal of PITR performance improvement for
> PostgreSQL 8.4 development. This proposal includes readahead
> mechanism of data pages which will be read by redo() routines in the
> recovery. This is especially effective in the reco
19 matches
Mail list logo
