> It may be that WAL has changed the rollback
> time-characteristics to worse than pre-wal ?

Nothing changed ... yet. And in future rollbacks
of read-only transactions will be as fast as now,
anyway.

> > So my guess is that the 7.1 updates (with default
> > fsync) are significantly slower than 7.0.3 fsync=off
> > now.

Do you update tables with foreign keys?
Did you run tests in multi-user or single-user
environment?

Vadim

-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com



Thu, 22 Feb 2001 09:40:09 -0500 (EST)
Vadim Mikheev <vadim4o@email.com>
Re: RE: Re: [ADMIN] v7.1b4 bad performance
Vadim Mikheev wrote:
> 
> > It may be that WAL has changed the rollback
> > time-characteristics to worse than pre-wal ?
> 
> Nothing changed ... yet. And in future rollbacks
> of read-only transactions will be as fast as now,
> anyway.

What about rollbacks of a bunch uf inserts/updates/deletes?

I remember a scenario where an empty table was used by several 
backends for gathering report data, and when the report is 
done they will rollback to keep the table empty.

Should this kind of usage be replaced in the future by 
having backend id as a key and then doing delete by that 
key in the end ?

--------------
Hannu

Thu, 22 Feb 2001 19:32:25 +0200
Hannu Krosing <hannu@tm.ee>
Re: RE: Re: [ADMIN] v7.1b4 bad performance
At 09:40 AM 22-02-2001 -0500, Vadim Mikheev wrote:
>> It may be that WAL has changed the rollback
>> time-characteristics to worse than pre-wal ?
>
>Nothing changed ... yet. And in future rollbacks
>of read-only transactions will be as fast as now,
>anyway.

The rollbacks are ok for me at least - even the 6.5.3 rollbacks are ok.

>> > So my guess is that the 7.1 updates (with default
>> > fsync) are significantly slower than 7.0.3 fsync=off
>> > now.
>
>Do you update tables with foreign keys?
>Did you run tests in multi-user or single-user
>environment?

No foreign keys. Multiuser- I had apachebench do a concurrency of two.
e.g.
ab -n 100 -c 2 "<url>"

7.1beta4 snapshot was giving about 22 hits per sec max. 7.0.3 was doing
about 60 hits per sec max. That's a significant difference in speed to me.

Thing is, it was only updating _one_ row in a table with only one row (and
committing). Everything else was selects.

The typical sequence was:

rollback;
begin;
select (session where supplied id and cookie matches and not timed out)
update session and set lastactive to 'now'
commit;
begin;
select (bunch of stuff);
.. (selects but no updates or inserts )
select (bunch of stuff);
rollback;

Any reason for the gradual slow down in both 7.0.3 (e.g. 60 hits/sec to 30)
and 7.1beta4 (e.g. 22 hits/sec to 15)? The session table expands due to the
concurrency? 

Should I switch to "select session .... for update"? Would that reduce the
gradual slowdown? 

The reason why I do so many rollbacks is because that appears to be the
recommended way to begin a new transaction using perl DBI - not supposed to
issue an explicit BEGIN. 

I do the first rollback/begin so I don't get stale transaction timestamps
from the previous  "last rollback".

I do the last rollback/begin in order to free up any locks, before waiting
for an undeterminable time for the next connection.

Cheerio,
Link.


Sat, 24 Feb 2001 10:22:08 +0800
Lincoln Yeoh <lyeoh@pop.jaring.my>
Re: RE: Re: [ADMIN] v7.1b4 bad performance