Re: Support Parallel Query Execution in Executor
От | Myron Scott |
---|---|
Тема | Re: Support Parallel Query Execution in Executor |
Дата | |
Msg-id | 1E8A8988-53CB-49F3-B4DE-75B567BF0529@sacadia.com обсуждение исходный текст |
Ответ на | Re: Support Parallel Query Execution in Executor (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
On Apr 9, 2006, at 9:26 AM, Martijn van Oosterhout wrote: > On Sun, Apr 09, 2006 at 08:23:36AM -0700, Myron Scott wrote: >>> This is the part I'm curious about - is this using the >>> shared_buffers region >>> in a circular buffer fashion to store pre-fetched pages? >> >> Yes. That is basically what the slave thread is trying to do. As >> well as weed out >> any tuples/pages that don't need to be looked at due to dead tuples. >> I did several things to try and insure that a buffer needed by the >> master thread >> would not be pulled out of the buffer pool before it was seen by the >> master. >> I wanted to do this without holding the buffer pinned, so I did the >> change to >> the buffer free list to do this. > > Is this necessary? I mean, what's the chance that a page might get > thrown out early? And if so, what's the chance that page will still be > in the OS cache? > > The cost of fetching a page from the OS is not really much of an > overhead, so I'd like to know how much benefit these buffer cache > hacks > actually produce. > You may be right on this one. I wanted ensure that I didn't lose pages I needed. I may have just added a belt to my suspenders. I'll add a switch to turn it off and on and try and devise a test to see what the costs either way are. Myron Scott
В списке pgsql-hackers по дате отправления: