Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: ice-broker scan thread


  • From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
  • To: pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: ice-broker scan thread
  • Date: Tue, 29 Nov 2005 00:09:11 -0500
  • Message-id: <dmgno1$21n8$1(at)news(dot)hub(dot)org>

"David Boreham" <david_list(at)boreham(dot)org> wrote
>
> BTW, I heard a long time ago that NTFS has quite fancy read-ahead, where 
> it attempts to detect the application's access pattern including if it is
> reading sequentially and even if there is a 'stride' to the accesses when
> they're not contiguous. I would imagine that other filesystems attempt 
> similar tricks. So one might expect a simple linear prefectch
> to not help much in the presence of such a filesystem.
>

So we need more tests. I understand how smart current file systems are, and 
seems that depends on the interval that you send next file block read 
request (decided by cpu_cost parameter in my program).

I imagine on a multi-way machine with strong IO device, the ice-breaker 
could do much better ...

> Were you worried about the icebreaker thread getting too far ahead of the 
> scan ? If it did it might page out the data you're about to read, I think. 
> Of course this could be fixed by having the read ahead thread perodically 
> check the current location being read by the query thread and pausing if 
> it's got too far ahead.
>

Right.

Regards,
Qingqing 





Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group