Hi Rob,
I have default B-Tree indexes created for each of the indexed columes and
primary key columes. (No multiple columes indexe or NULL FIRST or
DESC/ASC). I am using PostgreSQL 8.3 with the auto vacuum daemon on. I
assume analyse will be automatically run to collect statistics for use b
Hi Steve,
Thanks for you suggestions. In my senario, what is current depends on
users. Because if user wants a status report at 00:00 1st Jan 2009, then
00:00 1st Jan 2009 is current. So it is not possible to flag any records as
current unless the user tells us what is current.
cheers
Joh
Did you look at the query plans for the various record counts? That
might show which index is missing or misinformed :). I wonder if
clustering the status table on objectid would help? This does then
require maintenance so you might only load it at 75%.
wkipj...@gmail.com wrote:
Hi Rob,
wkipj...@gmail.com wrote:
I have the following senario.
I have a tracking system. The system will record the status of an
object regularly, all the status records are stored in one table. And
it will keep a history of maximum 1000 status record for each object
it tracks. The maximum objects t
I would be curious to know the performance curve for let's say 20K, 40K
, 60K, 80K, 100K records. And what sort of indexing you have, whether
or not it's clustered, re-built and so on.
One could envision partitioning the status table such that recent
records were grouped together (on the assu
