Hm, this is odd. That says you've got 349519 live index entries in
only
463 actively-used index pages, or an average of 754 per page, which
AFAICS could not fit in an 8K page. Are you using a nondefault value
of
BLCKSZ? If so what?
Sorry, I forgot to specify I use BLCKSZ of 32768, the same
=?ISO-8859-1?Q?Pailloncy_Jean-G=E9rard?= [EMAIL PROTECTED] writes:
Are you using a nondefault value of
BLCKSZ? If so what?
Sorry, I forgot to specify I use BLCKSZ of 32768,
Okay, the numbers are sensible then. The index density seems a bit low
(754 entries/page where the theoretical ideal
Hi,
I test many times the foolowing query.
dps=# explain analyze select next_index_time from url order by
next_index_time desc limit 1;
QUERY PLAN
=?ISO-8859-1?Q?Pailloncy_Jean-G=E9rard?= [EMAIL PROTECTED] writes:
How to optimize the last query ? (~ 2000 times slower than the first
one)
I suppose there is some odd distribution of data in the index ?
Looks to me like a whole lot of dead rows at the left end of the index.
Have you
Hi,
How to optimize the last query ? (~ 2000 times slower than the first
one)
I suppose there is some odd distribution of data in the index ?
Looks to me like a whole lot of dead rows at the left end of the index.
Have you VACUUMed this table lately?
From pg_autovacuum:
[2004-04-10 05:45:39 AM]
Hi,
In 7.4 a VACUUM should be sufficient ... or at least, if it isn't
Atfer VACUUM:
dps=# explain analyze select next_index_time from url order by
next_index_time desc limit 1;
QUERY PLAN
[ Ah, I just got to your message with the VACUUM VERBOSE results ... ]
=?ISO-8859-1?Q?Pailloncy_Jean-G=E9rard?= [EMAIL PROTECTED] writes:
dps=# VACUUM VERBOSE url;
INFO: index url_next_index_time now contains 349519 row versions in
3534 pages
DETAIL: 229515 index row versions were removed.
=?ISO-8859-1?Q?Pailloncy_Jean-G=E9rard?= [EMAIL PROTECTED] writes:
In 7.4 a VACUUM should be sufficient ... or at least, if it isn't
Atfer VACUUM:
Better, but..
... but not much :-(. Okay, could we see VACUUM VERBOSE results for
this table?
regards, tom lane
