Marten Feldtmann wrote:
> > You'll still have to do 6 queries in postgres because it does not return
> > fields in sub-classes.
>
> Practically this is not such a big problem as one might think.
> WHEN you have a persistance framework you tell your framework,
> that every attribut is located
Chris schrieb:
>
> > The point is: this is classic, but noone does it
> > like this if your really have a larger hierarchy of
> > classes. You'll not get any good performance, when
> > solving an association in your oo
> > program, because the framework has to query against
> > each table: 6 t
Hiroshi Inoue schrieb:
>
> Chris wrote:
>
> > It's pretty clear to me that an inherited index should be only one
> > index. There may be a case for optional non-inherited indexes (CREATE
> > INDEX ON ONLY foobar), but if the index is inherited, it is just one
> > index.
> >
> > At the end of t
> The point is: this is classic, but noone does it
> like this if your really have a larger hierarchy of
> classes. You'll not get any good performance, when
> solving an association in your oo
> program, because the framework has to query against
> each table: 6 tables - 6 queries !!! :-(((
Hiroshi Inoue wrote:
> > At the end of the day though, the reason is only performance. The
> > semantics should be the same no matter whether implemented as multiple
> > indexes or not. Performance is much better with one index though.(*)
> >
>
> Is it true ?
> How to guarantee the uniqueness us
Chris wrote:
> It's pretty clear to me that an inherited index should be only one
> index. There may be a case for optional non-inherited indexes (CREATE
> INDEX ON ONLY foobar), but if the index is inherited, it is just one
> index.
>
> At the end of the day though, the reason is only performan
It's pretty clear to me that an inherited index should be only one
index. There may be a case for optional non-inherited indexes (CREATE
INDEX ON ONLY foobar), but if the index is inherited, it is just one
index.
At the end of the day though, the reason is only performance. The
semantics should b
Alfred Perlstein wrote:
>* Oliver Elphick <[EMAIL PROTECTED]> [001018 04:59] wrote:
>> Do you mean that inheriting tables should share a single index with their
>> ancestors, or that each descendant should get a separate index on the
>> same pattern as its ancestors'?
>>
>> With the
* Oliver Elphick <[EMAIL PROTECTED]> [001018 04:59] wrote:
> Bruce Momjian wrote:
> >> Alfred Perlstein wrote:
> >> >
> >> > I noticed that INHERITS doesn't propogate indecies, It'd be nice
> >> > if there was an toption to do so.
> >>
> >> Yep it would. Are you volunteering?
> >>
Bruce Momjian wrote:
>> Alfred Perlstein wrote:
>> >
>> > I noticed that INHERITS doesn't propogate indecies, It'd be nice
>> > if there was an toption to do so.
>>
>> Yep it would. Are you volunteering?
>>
>
>Added to TODO:
>
> * Allow inherited tables to inherit inde
Alfred Perlstein wrote:
> Thank you, it's not a big problem that this doesn't happen, but it'd
> be nice to see it as an option when creating a table via inheritance.
>
> What about RULEs? I wouldn't really have a use for that but others
> might.
Actually it's a reasonably big deal. Apart from
* Bruce Momjian <[EMAIL PROTECTED]> [001016 08:55] wrote:
> > Alfred Perlstein wrote:
> > >
> > > I noticed that INHERITS doesn't propogate indecies, It'd be nice
> > > if there was an toption to do so.
> >
> > Yep it would. Are you volunteering?
> >
>
> Added to TODO:
>
> * Allow inher
> Alfred Perlstein wrote:
> >
> > I noticed that INHERITS doesn't propogate indecies, It'd be nice
> > if there was an toption to do so.
>
> Yep it would. Are you volunteering?
>
Added to TODO:
* Allow inherited tables to inherit index
--
Bruce Momjian| ht
13 matches
Mail list logo
