Re: 答复: [GENERAL] how to calculate or know seq_scan scan how many blocks every time - Mailing list pgsql-general

From Craig Ringer
Subject Re: 答复: [GENERAL] how to calculate or know seq_scan scan how many blocks every time
Date
Msg-id 50120445.3010001@ringerc.id.au
Whole thread Raw
In response to 答复: [GENERAL] how to calculate or know seq_scan scan how many blocks every time  ("leoxu" <leoxu8703@gmail.com>)
Responses 答复: 答复: [GENERAL] how to calculate or know seq_scan scan how many blocks every time  ("leoxu" <leoxu8703@gmail.com>)
List pgsql-general
On 07/27/2012 10:04 AM, leoxu wrote:
> Hello Craig:
>     I want to know a sequential scan( full scan table) it can read how many
> blocks every io?
>    I know scan index read is one block every io.
>
>    Oracle parameter db_file_multiblock_read_count it can control scattered
> read (full scan table),
>    assume db_file_multiblock_read_count =10,when scan full table,every io
> request blocks is 10 blocks.
>    I know scan index read is one block every io.
>
>    So I want to when  happen scan full table,postgresql scan full table scan
> how many blocks every io?

PostgreSQL uses the normal operating system facilities for file storage
and access to do its I/O, rather than doing direct unbuffered I/O to
files or even raw volumes like Oracle. It works quite differently, using
regular buffered I/O.

The amount of I/O required for and the I/O patterns of a sequential scan
in PostgreSQL depend on:

- The operating system readahead setting
- Whether the operating system has any of the desired blocks cached
- The file system and I/O scheduler in use

Because of that I'm not really sure your question can be answered,
except by benchmarking and real world measurement. PostgreSQL doesn't
really have the same concept of "an I/O" - though I guess a pread() call
would be fairly close.

What is your goal? What are you trying to achieve? Why are you trying to
determine this? What is the problem you are trying to solve?

--
Craig Ringer

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Schema-only dump dumps no constraints, no triggers
Next
From: hartrc
Date:
Subject: postgres maintenance db