We're in the process of buying another Opteron server to run Postgres, and
based on the suggestions in this list I've asked our IT director to get an
LSI MegaRaid controller rather than one of the Adaptecs.
But when we tried to place our order, our vendor (Penguin Computing) advised
us:
"we find
From: "Greg Stark" <[EMAIL PROTECTED]>
> Tom Lane <[EMAIL PROTECTED]> writes:
> Not as good as pruning partitions entirely but if you're doing a
sequential
> scan the performance hit of a few index lookups isn't a problem.
Greg, I think you've got the right idea. For large databases, though, it
w
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Stacy White" <[EMAIL PROTECTED]> writes:
> > FWIW, we see large benefits from partitioning other than the ability to
> > easily drop data, for example:
>
> > - We can vacuum only the active portio
From: "Tom Lane" <[EMAIL PROTECTED]>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > We probably also need multi-table indexes.
> As Josh says, that seems antithetical to the main point of partitioning,
> which is to be able to rapidly remove (and add) partitions of a table.
> If you have to do in
From: "Tom Lane" <[EMAIL PROTECTED]>
> Josh Berkus writes:
> > -- INSERT INTO should automatically create new partitions where
necessary
> > -- DELETE FROM should automatically drop empty partitions
>
> I am not sure I agree with either of those, and the reason is that they
> would turn low-lock o
The discussion seems to have diverged a little, so I don't feel too bad
about making some semi-off-topic comments.
From: "Greg Stark" <[EMAIL PROTECTED]>
> Like I said though, we found "global indexes" defeated the whole purpose.
First semi-off-topic comment: I think this depends on the index, th
rtitioning would introduce
a fairly significant amount of overhead. Correct?
- Original Message -
From: "Josh Berkus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Stacy White" <[EMAIL PROTECTED]>
Sent: Friday, December 10, 2004 9:52 PM
Subject:
idth=80) (never executed)
Total runtime: 31897.897 ms
(10 rows)
Time: 31900.204 ms
- Original Message -
From: "Josh Berkus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Stacy White" <[EMAIL PROTECTED]>
Sent: Sunday, December 05, 2004 3:06 PM
S
We're working with a Postgres database that includes a fairly large table
(100M rows, increasing at around 2M per day).
In some cases we've seen some increased performance in tests by splitting
the table into several smaller tables. Both 'UNION ALL' views, and the
superclass/subclass scheme work
