> > Good advice, except if the table is huge :-)
>
> ... Then the table shouldn't be designed to be huge. That represents
> a design error.
[snip]
> This demonstrates that "archival" material and "active" data should be
> kept separately.
>
> They have different access patterns; kludging them into the same table
> turns out badly.
Well, then please help me find a better design cause I can't see one...
what we have here is a big "membership" table of email lists. When
there's a sendout then the memberships of the affected group are heavily
read/updated, otherwise they are idle. None of the memberships is
archive data, they are all active data... the only problem is that they
are so many. Is it so hard to believe that >100 million rows is all
active data, but only used in bursts once per week (that's an example,
some groups are more active, others less) ?
Cheers,
Csaba.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
