Stacy,
Thanks for the stats!
> 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 well at pruning down the set of rows a
> query uses, but they seem to introduce a large performance hit to the time
> to process each row (~50% for superclass/subclass, and ~150% for union
> views).
This seems reasonable, actually, given your test. Really, what you should be
comparing it against is not against selecting from an individual partition,
but selecting from the whole business as one large table.
I also suspect that wider rows results in less overhead proportionally; note
that your test contains *only* the indexed rows. I should soon have a test
to prove this, hopefully.
However, I would be interested in seeing EXPLAIN ANALYZE from your tests
rather than just EXPLAIN.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
