Re: V4 of PITR performance improvement for 8.4

From: Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: V4 of PITR performance improvement for 8.4
Date: 2009-01-26 07:49:03
Message-ID: a778a7260901252349g24f6b1deya6e9b9bfed8697e5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

It's simply because we should not refer to system catalog during the recovery.

2009/1/25 Gregory Stark <stark(at)enterprisedb(dot)com>:
>
> Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com> writes:
>
>> Please find enclosed 2nd patch of pg_readahead which include a patch
>> to bufer manager to skip prefetch of pages already in shared buffer.
>
> I'm a bit confused by this comment. PrefetchBuffer already checks if the page
> is in shared buffers.
>
> What is tricky to avoid is prefetching the same page twice -- since the first
> prefetch doesn't actually put it in shared buffers there's no way to avoid
> prefetching it again unless you keep some kind of hash of recently prefetched
> buffers.
>
> For the index scan case I'm debating about whether to add such a cache
> directly to PrefetchBuffer -- in which case it would remember if some other
> scan prefetched the same buffer -- or to keep it in the index scan code.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's On-Demand Production Tuning
>

--
------
Koichi Suzuki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-01-26 07:58:02 gin fast insert performance
Previous Message Heikki Linnakangas 2009-01-26 07:48:20 Re: FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory