From: | Franck Routier <franck(dot)routier(at)axege(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Disk usage question |
Date: | 2008-11-12 17:02:31 |
Message-ID: | 1226509351.21212.20.camel@franck-laptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
I have to manage a database that is getting way too big for us.
Currently db size is 304 GB.
One table is accounting for a third of this space.
The table itself has 68.800.000 tuples, taking 28GB.
There are 39 indices on the table, and many of them use multiple
columns. A lot of these indices share the same column(s).
The indices are taking 95GB.
So, here are my questions:
- do these figures seem normal or is there likely a bigger problem ?
- when indices share a column, is it worth creating several multi-column
indices (as we do now), or would we get the same result (from a
performance point of view) by creating several single column indices
(one for each column) ?
- does the order in which a multi-column index is created matter ? That
is, if I have a column A with less discriminating values and a column B
with more discriminating values, does it matter if I:
'CREATE INDEX myindex ON mytable USING (A,B) '
or
'CREATE INDEX myindex ON mytable USING (A,B) '
Is the second solution likely to behave faster ?
Or is it simply better to:
CREATE INDEX myindexa ON mytable USING (A);
CREATE INDEX myindexb ON mytable USING (B);
- as we do many insert and very few update/delete, I thought REINDEX was
going to be superfluous. But REINDEXing is often needed to keep the size
of the db _relatively_ reasonable. Does it sound normal ?
Thanks for any tip,
Franck
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Hevia | 2008-11-12 17:16:11 | Re: Performance Question |
Previous Message | Andrus | 2008-11-12 17:02:10 | Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed |