Re: Synchronized Scan update
От | Jeff Davis |
---|---|
Тема | Re: Synchronized Scan update |
Дата | |
Msg-id | 1173807387.23455.107.camel@dogma.v10.wvs обсуждение исходный текст |
Ответ на | Re: Synchronized Scan update ("Simon Riggs" <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, 2007-03-13 at 17:17 +0000, Simon Riggs wrote: > On Tue, 2007-03-13 at 10:08 -0700, Jeff Davis wrote: > > On Tue, 2007-03-13 at 12:53 -0400, Tom Lane wrote: > > > Jeff Davis <pgsql@j-davis.com> writes: > > > > I agree that ss_report_loc() doesn't need to report on every call. If > > > > there's any significant overhead I agree that it should report less > > > > often. Do you think that the overhead is significant on such a simple > > > > function? > > > > > > One extra LWLock cycle per page processed definitely *is* a significant > > > overhead ... can you say "context swap storm"? I'd think about doing it > > > once every 100 or so pages. > > > > > > > No lock is needed to store the hint. If somehow the hint (which is > > stored in a static table, no pointers) gets invalid data due to a race > > condition, the new scan will simply consider the hint invalid and start > > at 0. > > > > I did this precisely to avoid causing a performance regression for usage > > patterns that don't benefit from sync scans. > > Shared memory access is still a performance/scalability concern because > so many people want access to it at the same time. > > There really is no need to do this after each block. 8 CPUs ought to be > able to do 8 scans without tripping over each other. Especially if they > are on separate tables. > Ok, I'll do it every 100 pages. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: