On Sat, Aug 20, 2005 at 11:08:13PM +1000, Gavin Sherry wrote:
> Of course. The idea is that, generally speaking, you're only interested in
> a small portion of the data stored in the table. Indexes store extra data
> so that they can locate the portion you're interested in faster.
I think his ques
On Sat, 20 Aug 2005 ohp@pyrenet.fr wrote:
> Hi,
>
> While testing 8.1dev I came to this:
>
> CREATE TABLE t (
> a int,
> b int
> PRIMARY KEY (a,b));
>
> In that case, the index is as big as the table.
Right. Think about it: the index must store a, b, a reference to the data
in the table itself a
Hi,
While testing 8.1dev I came to this:
CREATE TABLE t (
a int,
b int
PRIMARY KEY (a,b));
In that case, the index is as big as the table.
My question is is it worthwhile to have such index peformance wise.
I understand I'd loose uniqness buthas such an index any chance to be used
against seq
