>
> 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
------------------------------
