Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
Hmm. The theory I'd developed for what I see here is that the slow
timings correspond to when the pgstat code decides
Hello,
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Pavel Stehule [EMAIL PROTECTED] writes:
Hello,
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
Hm, Presumably this is on a machine where the visibility map is entirely in
cache too.
Pavel Stehule wrote:
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
How did you measure that?
I tried to reproduce that here, and indeed it seems to be much slower on
CVS HEAD than
Heikki Linnakangas escribió:
Oprofile suggests that most of the time is actually spent in
pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
called by pgstat_vacuum_stat.
Hmm, that routine is expensive. Calling it for every vacuum is not good
:-( Fortunately,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Oprofile suggests that most of the time is actually spent in
pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
called by pgstat_vacuum_stat.
We added support for tracking call counts and elapsed runtime of
user-defined
Alvaro Herrera [EMAIL PROTECTED] writes:
In the end, it would be better if this function was not called at all
for user-invoked vacuum, and have autovacuum handle it. However, that
doesn't work for people who disable autovacuum.
A possible variant on that is to invoke it only in database-wide
I wrote:
... In particular we should at least try to bypass the pg_proc scan when
there are *no* function stats records.
That idea, at least, looks to be trivial to implement; so I'll go do so.
regards, tom lane
--
Sent via pgsql-hackers mailing list
2008/12/8 Heikki Linnakangas [EMAIL PROTECTED]:
Pavel Stehule wrote:
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
How did you measure that?
it's simple test
create table x(a
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/8 Heikki Linnakangas [EMAIL PROTECTED]:
How did you measure that?
it's simple test
create table x(a integer, b integer);
insert into x select i, i from generate_series(1,1000) g(i);
and then vacuum on 8.3.5 and vacuum on current CVS HEAD.
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
postgres=# VACUUM x;
VACUUM
Time: 12,093 ms
postgres=# VACUUM x;
VACUUM
Time: 1,928 ms
postgres=# VACUUM x;
VACUUM
Time: 10,743 ms
postgres=# VACUUM x;
VACUUM
Time: 1,927 ms
postgres=#
Pavel Stehule [EMAIL PROTECTED] writes:
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
Hmm. The theory I'd developed for what I see here is that the slow
timings correspond to when the pgstat code decides it needs a new stats
file
12 matches
Mail list logo
