Heikki Linnakangas wrote:
> How about:
>
> * Speed WAL recovery by allowing more than one page to be prefetched
>
> This should be done utilizing the same infrastructure used for
> prefetching in general, to avoid introducing complex, error-prone code
> to WAL replay codepath, which doesn't get much testing compared to the
> rest of the system.
Updated to:
* Speed WAL recovery by allowing more than one page to be prefetched
This should be done utilizing the same infrastructure used for
prefetching in general to avoid introducing complex error-prone code
in WAL replay.
> There's already this TODO item:
>
> > Experiment with multi-threaded backend better resource utilization
> >
> > This would allow a single query to make use of multiple CPU's or multiple I/O channels simultaneously. One idea is
tocreate a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be
expandedto allow concurrent reads from multiple devices in a partitioned table.
>
> This should probably be split into two. Using multiple CPUs for
> satisfying one query is quite different from implementing some kind of a
> pre-fetching mechanism using posix_fadvise(), libaio, or background
> reader processes.
Good idea, items split:
* Experiment with multi-threaded backend better I/O utilization
This would allow a single query to make use of multiple I/O channels
simultaneously. One idea is to create a background reader that can
pre-fetch sequential and index scan pages needed by other backends.
This could be expanded to allow concurrent reads from multiple devices
in a partitioned table.
* Experiment with multi-threaded backend better CPU utilization
This would allow several CPUs to be used for a single query, such as
for sorting or query execution.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
