Re: Various silliness in heap_getnext and related routines
От | bruc@stone.congenomics.com (Robert E. Bruccoleri) |
---|---|
Тема | Re: Various silliness in heap_getnext and related routines |
Дата | |
Msg-id | 200106111604.MAA90168@stone.congenomics.com обсуждение исходный текст |
Ответ на | Re: Various silliness in heap_getnext and related routines (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Various silliness in heap_getnext and related routines
|
Список | pgsql-hackers |
Dear Tom, > > > bruc@stone.congenomics.com (Robert E. Bruccoleri) writes: > > For my immediate problem, would removing the spinlock acquisition > > be OK? > > It'd be interesting to remove the marked lines: > > bufHdr = &BufferDescriptors[buffer - 1]; > - SpinAcquire(BufMgrLock); > if (bufHdr->tag.blockNum == blockNumber && > RelFileNodeEquals(bufHdr->tag.rnode, relation->rd_node)) > { > - SpinRelease(BufMgrLock); > return buffer; > } > - return ReadBufferWithBufferLock(relation, blockNumber, true); > > and see how that affects your performance issue, if at all. > I have made those changes, ran the regression tests, and then issued eight simultaneous retrieval jobs against the database. Performance is now greatly improved with all the jobs making quick progress through the sequential query and completing in very reasonable times. Thanks very much for your help. BTW, given the high level of support that you provide to the PostgreSQL community, it's very accurate to state that support for PostgreSQL is far superior to that of Oracle, especially for SGI systems. Sincerely, Bob +----------------------------------+------------------------------------+ | Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383 | | President, Congenomics, Inc. | Fax: 609 737 7528 | | 114 W Franklin Ave, Suite K1,4,5 | email: bruc@acm.org | | P.O. Box 314 | URL: http://www.congen.com/~bruc | | Pennington, NJ 08534 | | +----------------------------------+------------------------------------+
В списке pgsql-hackers по дате отправления: