Thanks for the feedback!
We saw consistent slowdowns with several test programs using both BMP and
CMP. From my notes vacuum would reclaim data space, but not index files,
and a recreate primary key reduced the index file from 3.1m to 1.6k on a
table with one row. Doing this every time gave consistent run
times. Tuning attempts improved run times, but not the increases in time
and space.
We ran postgresql (6.5.3 and 7.0) on Redhat 6.2, and Orion and our test
clients on Win98. The tests basically created 1000 copies each of about 5
beans and then removed them. One EB was accessed through a SSB, the rest
directly from the client. We did not explicitly specify any transaction
attributes.
Does your application remove a large number of rows? This looked like a
problem with deleted space recovery. I assumed from having an explicit
command to reclaim storage, and the documentation's recommendation to run
it daily, that postgresql was a bit weak in this area.
Any ideas where I might have gone wrong? I'd like to try it again.
Kirk Yarina
At 01:49 PM 8/15/00 +1000, you wrote:
>We are using Orion with Postgres v7 here and we have no such problem.
>
>On Mon, Aug 14, 2000 at 12:06:07PM -0400, KirkYarina wrote:
> > FWIW, we found major problems with postgresql. Running a test that
> created
> > and deleted EBs caused index and data files to grow
<snip>
Kirk Yarina
[EMAIL PROTECTED]
