On Mon, 2004-02-02 at 13:43, Tomasz Myrta wrote:
> Dnia 2004-02-02 19:30, Użytkownik scott.marlowe napisał:
> > Not entirely, since it only has to sort two columns, it will be smaller,
> > and will therefore be somewhat faster.
>
> Can you say something more about it? Will it be enough faster to
On Mon, 2 Feb 2004, Tomasz Myrta wrote:
> Dnia 2004-02-02 19:30, U¿ytkownik scott.marlowe napisa³:
> > Not entirely, since it only has to sort two columns, it will be smaller,
> > and will therefore be somewhat faster.
>
> Can you say something more about it? Will it be enough faster to keep
>
Dnia 2004-02-02 19:30, Użytkownik scott.marlowe napisał:
Not entirely, since it only has to sort two columns, it will be smaller,
and will therefore be somewhat faster.
Can you say something more about it? Will it be enough faster to keep
them both? Did anyone make such tests?
Regards,
Tomasz My
On Mon, 2 Feb 2004, Tomasz Myrta wrote:
> Dnia 2004-02-02 15:46, U?ytkownik Rigmor Ukuhe napisa3:
> > Hi,
> >
> > I have many indexes somehow overlaping like:
> > ... btree ("STATUS", "VISIBLE", "NP_ID");
> > ... btree ("STATUS", "VISIBLE");
> >
> > is perfomance gained by "more exact" index wor
Dnia 2004-02-02 15:46, Użytkownik Rigmor Ukuhe napisał:
Hi,
I have many indexes somehow overlaping like:
... btree ("STATUS", "VISIBLE", "NP_ID");
... btree ("STATUS", "VISIBLE");
is perfomance gained by "more exact" index worth overhead with managing
indexes.
The second (2 columns) index is usele
