Re: Piggybacking vacuum I/O

On 1/25/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>
> Pavan Deolasee wrote:
> >
> > Also is it worth optimizing on the total read() system calls which might
> > not
> > cause physical I/O, but
> > still consume CPU ?
>
> I don't think it's worth it, but now that we're talking about it: What
> I'd like to do to all the slru files is to replace the custom buffer
> management with mmapping the whole file, and letting the OS take care of
> it. We would get rid of some guc variables, the OS would tune the amount
> of memory used for clog/subtrans dynamically, and we would avoid the
> memory copying. And I'd like to do the same for WAL.

Yes, we can do that. One problem though is mmaping wouldn't work when
CLOG file is extended and some of the backends may not see the extended
portion. But may be we can start with a sufficiently large initialized file
and
mmap the whole file.

Another simpler solution for VACUUM would be to read the entire CLOG file
in local memory. Most of the transaction status queries can be satisfied
from
this local copy and the normal CLOG is consulted only when the status is
unknown (TRANSACTION_STATUS_IN_PROGRESS)

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com