On Dec 7, 2005, at 10:46 , Christopher Kings-Lynne wrote:
In case you didn't know btw, MySQL 5.1 is out with rather extensive
table partition support. So get coding :D
You do mean MySQL 5.1 alpha is out, right?
Michael Glaesemann
grzm myrealbox com
---(end of broa
One of the easier cases would be non-overlapping (exclusive) constraints
on union subtables on the joined column.
This could serve as a "partition key", or in case of many nonoverlapping
columns (ex.: table is partitioned by date and region), as many
partition keys.
Yes, thats my planned direc
On Tue, 2005-12-06 at 16:12 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, L, 2005-12-03 kell 09:21, kirjutas Simon Riggs:
>
> > First off, I think we need to do some more work on partitioning so that
> > some knowledge about the union set is understood by the optimizer. At
> > the moment there
Ühel kenal päeval, L, 2005-12-03 kell 09:21, kirjutas Simon Riggs:
> First off, I think we need to do some more work on partitioning so that
> some knowledge about the union set is understood by the optimizer. At
> the moment there is no concept of partition key, so its hard to spot
> when two uni
>There's a number of things that can be pushed down over a union set, in
>certain circumstances.
>
FWIW, you should also be able to push the unions up.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
On Fri, 2005-12-02 at 19:43 -0500, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> (The larger point that joins of inheritance unions aren't well-planned
> >> is true, but it's always been true...)
>
> > It also seems to have a probkem with unions in views.
>
> > Is there anythin
Tom Lane wrote:
>It's something that's on the ever-growing TODO list ... I dunno if
>anyone has any near-term plans to work on it. It'd definitely be
>nice to teach the planner to do joins-over-unions well, and then
>make inheritance just invoke that behavior instead of being a crocky
>special ca
Philip Warner <[EMAIL PROTECTED]> writes:
>> (The larger point that joins of inheritance unions aren't well-planned
>> is true, but it's always been true...)
> It also seems to have a probkem with unions in views.
> Is there anything that can be done about this -- workarounds etc? Any
> plans to
>Is it intentional that your test case omits an analyze on t2?
>
No; my mistake.
>(The larger point that joins of inheritance unions aren't well-planned
>is true, but it's always been true...)
It also seems to have a probkem with unions in views.
Is there anything that can be done about this --
Philip Warner <[EMAIL PROTECTED]> writes:
> The optimizer seems to want to use sequential scans on inherited tables
> when crossed with another table, as the following seems to demonstrate:
Is it intentional that your test case omits an analyze on t2? Coz when
I add that, I get the same plan you
The optimizer seems to want to use sequential scans on inherited tables
when crossed with another table, as the following seems to demonstrate:
Create Table base(f1 bigserial);
create table inh1(f2 bigint) inherits (base);
create table inh2(f2 bigint) inherits (base);
create table inh3(f2 bigint)
11 matches
Mail list logo
