[HACKERS] Re: [QUESTIONS] Reliability?
| От | Bruce Momjian |
|---|---|
| Тема | [HACKERS] Re: [QUESTIONS] Reliability? |
| Дата | |
| Msg-id | f3dc17b1dab78c44ce7ecea6d73228a0 обсуждение исходный текст |
| Список | pgsql-hackers |
> > Marc G. Fournier wrote: > > > > On Tue, 10 Jun 1997, Craig S. Anderson wrote: > > > > > - Overall, performance is poor. Postgres uses table-level locking, > > > which hurts concurrent performance and can cause spurious deadlock situations. > > > I could only get acceptable performance running with fsyncs > > > disabled, which corrupted the database when I had a crash. > > > > Vadim, I believe, is working on this after v6.1 is released... > > Yes, and I hope to see highest concurrent performance due to the > fact that postgres is multi-version system. > As for fsync - someday we'll got rid of unnecessary fsyncs in > buffer manager (believe me - there are many of them) and there > will be no reasons to turn it off. I always suspected there were too many fsync's in there. > > > > > > - Indices on small tables which have many inserts and deletes > > > performed on them grow without bound to many megabytes in size, > > > even though the indexed table has no rows. > > > > Haven't noticed this with the v6.1 I have in production right now... > ^^^^^^^^^^^^^^^ > I assume that you insert rows with the same values in indexed > columns as they were in deleted rows. Index pages may be re-used > for new rows in this case. But if there is index over oid > (for example) and even all records were deleted from table - > inserting new rows will add new pages to the index because of > new values of oids will not be in the range of old values. > Keep thinking how to re-use empty index pages automatically... Added to TODO list. > It's from cache invalidation code (I believe) - sinvaladt.h: > /* Parameters (configurable) *******************************************/ > ^^^^^^^^^^^^ - did you try ? > #define MaxBackendId 32 /* maximum number of backends */ > ^^ > Someday we implement shared system cache and get rid of this code, > and significantly improve concurrency perfomance... I have added this item to the FAQ. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
В списке pgsql-hackers по дате отправления: