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:
Hi!
I'm just wondering, I've got a table that is partitioned into monthly
tables:
media_downloads -> media_downloads_MM
I\- id (primary key)
\- created_on (timestamp criteria for the monthly table split)
There are constraints upon the created_on column, all needed insert
instead rules are
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
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
17 matches
Mail list logo
