But then what about the null values? Perhaps unique + notnull is better?
Otto
2007/4/20, Nicolas Barbier <[EMAIL PROTECTED]>:
2007/4/16, Ottó Havasvölgyi <[EMAIL PROTECTED]>:
> Eliminate the table T from the query/subquery if the following
requirements
> are satisfied:
> 1. T is left joined
2007/4/16, Ottó Havasvölgyi <[EMAIL PROTECTED]>:
Eliminate the table T from the query/subquery if the following requirements
are satisfied:
1. T is left joined
2. T is referenced only in the join expression where it is left joined
3. the left join's join expression is a simple equality expressio
Hi,
Could you Bruce please add a TODO item for this feature?
The description could look something like this:
Eliminate the table T from the query/subquery if the following requirements
are satisfied:
1. T is left joined
2. T is referenced only in the join expression where it is left joined
3. th
> I have this exact problem a lot. There are actually cases
> where you can eliminate regular joins, not just left joins.
> For example:
>
> CREATE TABLE partner (
> id serial,
> namevarchar(40) not null,
> primary key (id)
> );
>
>
I have this exact problem a lot. There are actually cases where you can
eliminate regular joins, not just left joins. For example:
CREATE TABLE partner (
id serial,
namevarchar(40) not null,
primary key (id)
);
CREATE TABLE projec
On Wed, 11 Apr 2007, Jim Nasby wrote:
> I agree with others that the way that query is constructed is a bit
> odd, but it does bring another optimization to mind: when doing an
> inner-join between a parent and child table when RI is defined
> between them, if the query only refers to the child ta
> Maybe odd, but simpler to optimize this way.
>
> Your idea would be also a very good optimization, there was
> already a discussion about that here:
> http://archives.postgresql.org/pgsql-performance/2006-01/msg00
> 151.php, but that time Tom refused it because it was too
> expensive and rare
Jim,
Maybe odd, but simpler to optimize this way.
Your idea would be also a very good optimization, there was already a
discussion about that here:
http://archives.postgresql.org/pgsql-performance/2006-01/msg00151.php, but
that time Tom refused it because it was too expensive and rare. Maybe now
I agree with others that the way that query is constructed is a bit
odd, but it does bring another optimization to mind: when doing an
inner-join between a parent and child table when RI is defined
between them, if the query only refers to the child table you can
drop the parent table from
My mapper joins the parent classes' tables to the current class' table in
the view. In the ShapeView only ID, X, and Y is selected from the shape
table, and none of the child tables are touched, opposite to your sample.
But even though all Shape objects (circles and rectangles too) are in the
resu
2007/4/7, Ottó Havasvölgyi <[EMAIL PROTECTED]>:
My simple example:
Class hierarchy and fields:
Shape (ID, X, Y)
|
+-Circle (ID, Radius)
|
+-Rectangle (ID, Width, Height)
The mapper creates 3 tables with the columns next to the class name.
And it creates 3 views. One of them:
RectangleView: S
Sorry, I have left out the PK requirement.
What Nicolas wrote is right, I also use an O/R mapper and inheritance is
solved with vertical partitioning. The tables are connected to each other
with the PK. And the mapper defines views for each class with left joins.
The mapper generates queries based
2007/4/7, Andreas Pflug <[EMAIL PROTECTED]>:
Tom Lane wrote:
"=?ISO-8859-1?Q?Ott=F3_Havasv=F6lgyi?=" <[EMAIL PROTECTED]> writes:
When using views built with left joins, and then querying against these
views, there are a lot of join in the plan that are not necessary, because I
don't select/u
On Fri, 2007-04-06 at 19:38 -0400, Tom Lane wrote:
> "=?ISO-8859-1?Q?Ott=F3_Havasv=F6lgyi?=" <[EMAIL PROTECTED]> writes:
> > When using views built with left joins, and then querying against these
> > views, there are a lot of join in the plan that are not necessary, because I
> > don't select/use
Tom Lane wrote:
> "=?ISO-8859-1?Q?Ott=F3_Havasv=F6lgyi?=" <[EMAIL PROTECTED]> writes:
>
>> When using views built with left joins, and then querying against these
>> views, there are a lot of join in the plan that are not necessary, because I
>> don't select/use any column of each table in the v
"=?ISO-8859-1?Q?Ott=F3_Havasv=F6lgyi?=" <[EMAIL PROTECTED]> writes:
> When using views built with left joins, and then querying against these
> views, there are a lot of join in the plan that are not necessary, because I
> don't select/use any column of each table in the views every time. Tables
>
16 matches
Mail list logo
