Re: [PERFORMANCE] Insights: fseek OR read_cluster?

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Antonio Rodriges <antonio(dot)rrz(at)gmail(dot)com>
Cc: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORMANCE] Insights: fseek OR read_cluster?
Date: 2011-09-26 19:06:51
Message-ID: CABRT9RDEne4S5DWHdL9N+inG7e+PLTFtv78YZ=CEZHSbhUmGxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Sep 26, 2011 at 15:51, Antonio Rodriges <antonio(dot)rrz(at)gmail(dot)com> wrote:
>> What is read_cluster()  ? Are you talking about some kind of async and/or
>
> I meant that if you want to read a chunk of data from file you (1)
> might not call traditional fseek but rather memorize hard drive
> cluster numbers to boost disk seeks and, (2) perform the read of disk
> cluster directly.

PostgreSQL accesses regular files on a file system via lseek(), read()
and write() calls, no magic.

In modern extent-based file systems, mapping a file offset to a
physical disk sector is very fast -- compared to the time of actually
accessing the disk.

I can't see how direct cluster access would even work, unless you'd
give the database direct access to a raw partition, in which case
Postgres would effectively have to implement its own file system. The
gains are simply not worth it for Postgres, our developer resources
are better spent elsewhere.

Regards,
Marti

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message M. D. 2011-09-26 20:13:10 Re: slow query on tables with new columns added.
Previous Message Tom Lane 2011-09-26 17:35:11 Re: Performance Anomaly with "col in (A, B)" vs. "col = A OR col = B" ver. 9.0.3