On Mon, 2006-10-30 at 22:58 +0100, Andreas Kostyrka wrote:
> Am Montag, den 30.10.2006, 08:18 + schrieb Simon Riggs:
> > On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
> >
> > > Any ideas how to make the optimizer handle partitioned tables more
> > > sensible?
> >
> > Yes, those
Am Montag, den 30.10.2006, 08:18 + schrieb Simon Riggs:
> On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
>
> > Any ideas how to make the optimizer handle partitioned tables more
> > sensible?
>
> Yes, those are known inefficiencies in the current implementation which
> we expect
On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
> Any ideas how to make the optimizer handle partitioned tables more
> sensible?
Yes, those are known inefficiencies in the current implementation which
we expect to address for 8.3.
--
Simon Riggs
EnterpriseDB http:
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
On Wed, Dec 15, 2004 at 11:56:40AM -0800, Josh Berkus wrote:
> Greg,
>
> > Well Oracle has lots of partitioning intelligence pushed up to the planner
> > to avoid overhead.
> >
> > If you have a query with something like "WHERE date = '2004-01-01'" and
> > date is your partition key (even if it's
Sorry for the late reply, so I included the whole thread. Should this be
a TODO?
On Wed, Dec 15, 2004 at 08:30:08PM -0500, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > But I'm a bit puzzled. Why would Append have any significant cost? It's just
> > taking the tuples from one plan n
Greg Stark <[EMAIL PROTECTED]> writes:
> But I'm a bit puzzled. Why would Append have any significant cost? It's just
> taking the tuples from one plan node and returning them until they run out,
> then taking the tuples from another plan node. It should have no i/o cost and
> hardly any cpu cost.
Josh Berkus <[EMAIL PROTECTED]> writes:
> > But I'm a bit puzzled. Why would Append have any significant cost? It's
> > just taking the tuples from one plan node and returning them until they run
> > out, then taking the tuples from another plan node. It should have no i/o
> > cost and hardly any
Josh Berkus <[EMAIL PROTECTED]> writes:
> Stacy,
>
> > Thanks again for the reply. So it sounds like the answer to my original
> > question is that it's expected that the pseudo-partitioning would introduce
> > a fairly significant amount of overhead. Correct?
>
> Correct. For that matter, O
Greg,
> Well Oracle has lots of partitioning intelligence pushed up to the planner
> to avoid overhead.
>
> If you have a query with something like "WHERE date = '2004-01-01'" and
> date is your partition key (even if it's a range) then Oracle will figure
> out which partition it will need at plan
Stacy,
> Thanks again for the reply. So it sounds like the answer to my original
> question is that it's expected that the pseudo-partitioning would introduce
> a fairly significant amount of overhead. Correct?
Correct. For that matter, Oracle table partitioning introduces significant
overhe
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:
Stacy,
> Each set of test tables holds 1,000,000 tuples with a partition value of
> '1', and 1,000,000 with a partition value of '2'. The bar* columns are all
> set to non-null values. The 'one_big_foo' table stores all 2M rows in one
> table. 'super_foo' and 'union_foo' split the data into two
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
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 la
15 matches
Mail list logo
