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

Re: ice-broker scan thread

From: "Pollard, Mike" <mpollard(at)cincom(dot)com>
To: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Cc: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ice-broker scan thread
Date: 2005-11-29 15:11:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
No, I only go x number of pages ahead of the user scan (where x is
currently user defined, but it should be significantly smaller than your
number of data buffers).  I have found that reading about 16Mb ahead
gives optimal performance, and on modern machines isn't all that much
memory.  Once the user scan has processed most of that 16Mb, the next
section of the tree is schedule to be read.  I don't keep the read ahead
threads a constant distance ahead, because I found it to be more
efficient if they occasionally had a lot of pages to read at once,
rather than constantly having a few pages to read.

Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
 Better to remain silent and be thought a fool than to speak out and
remove all doubt.
         Abraham Lincoln

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog(at)svana(dot)org] 
Sent: Tuesday, November 29, 2005 10:06 AM
To: Pollard, Mike
Cc: Qingqing Zhou; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] ice-broker scan thread

On Tue, Nov 29, 2005 at 09:45:30AM -0500, Pollard, Mike wrote:
> Anyway, what I did was the following.  When doing a sequential scan,
> were starting at the beginning of the table and scanning forward.  If
> threw up some threads to read ahead, then my user thread and my read
> ahead threads would thrash on trying to lock the buffer slots.  So, I


> so above, the user threads is starting low in the table and working
> high; the readahead threads are starting higher (but not at the end of
> the table), and working low.  

Ok, this may be a really dumb question, but doesn't this rely on the
fact that the table is smaller than the amount of buffers? If the table
is large most of your data will be tossed out again by later data
before it's been used by the backend.

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is
> tool for doing 5% of the work and then sitting around waiting for
> else to do the other 95% so you can sue them.

pgsql-hackers by date

Next:From: Andrew PiskorskiDate: 2005-11-29 15:22:56
Subject: Re: ice-broker scan thread
Previous:From: Martijn van OosterhoutDate: 2005-11-29 15:06:18
Subject: Re: ice-broker scan thread

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group