In the last episode (Nov 19), Benjamin Pflugmann said:
> On Mon 2002-11-18 at 19:01:57 -0500, [EMAIL PROTECTED] wrote:
> [...]
> > A BITMAP index will work efficiently in this case, no matter what
> > the distribution of the keys is. The only requirement is that the
> > column be low-cardinality.
Hi.
On Mon 2002-11-18 at 19:01:57 -0500, [EMAIL PROTECTED] wrote:
[...]
> A BITMAP index will work efficiently in this case, no matter what the
> distribution of the keys is. The only requirement is that the column be
> low-cardinality.
>
> It basically works like this:
>
> true 01101
> f
On Mon, 2002-11-18 at 16:22, Michael T. Babcock wrote:
> Neulinger, Nathan wrote:
>
> >It's actually relatively speedy WITH the bad index, but maintaining that
> >index (given it's lopsided nature) is very expensive.
> >
> >Yes, the point is to ONLY index the row if it matches the restriction.
>
Neulinger, Nathan wrote:
It's actually relatively speedy WITH the bad index, but maintaining that
index (given it's lopsided nature) is very expensive.
Yes, the point is to ONLY index the row if it matches the restriction.
To clarify, if MySQL is indexing a binary value with lopsided
distr
On Tue, Nov 19, 2002 at 07:12:27AM +1100, Dean Harding wrote:
> Actually, it's a slightly different problem - a very uneven distribution
> of values on a column, not a small number of possible values like a
> bitmap index is for.
Exactly.
> In my opinion, this is a pretty useless feature, I mean
e index if
> it matches the WHERE clause. That'd speed up the index management as
> well.
>
> Dean Harding.
>
> > -Original Message-
> > From: Daniel Koch [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, 19 November 2002 5:58 am
> > To: [EMAIL PROTECT
]
> Sent: Tuesday, 19 November 2002 5:58 am
> To: [EMAIL PROTECTED]
> Cc: Egor Egorov; Neulinger, Nathan; Jeremy Zawodny
> Subject: Re: feature suggestion - indexes with "where" clause or
similar
>
> On Mon, 2002-11-18 at 12:29, Jeremy Zawodny wrote:
>
> > >
On Mon, 2002-11-18 at 12:29, Jeremy Zawodny wrote:
> > If I've got you right status can have values 0 or 1. In this case
> > you can just use " SELECT ... WHERE status=1 .." (index wil be used)
> > or "SELECT .. WHERE status=0 .." (index will not be used, because
> > scan the whole table will be f
On Mon, Nov 18, 2002 at 05:38:00PM +0200, Egor Egorov wrote:
> Neulinger,
> Friday, November 15, 2002, 7:25:27 PM, you wrote:
>
> NN> Assume I have a mysql table (myisam most likely) with a few hundred
> NN> thousand rows in it. One of the columns indicates success or failure.
> NN> 99.9% of the r
Neulinger,
Friday, November 15, 2002, 7:25:27 PM, you wrote:
NN> Assume I have a mysql table (myisam most likely) with a few hundred
NN> thousand rows in it. One of the columns indicates success or failure.
NN> 99.9% of the rows will have "0" in that column. But a small number will
NN> have 1. I n
Assume I have a mysql table (myisam most likely) with a few hundred
thousand rows in it. One of the columns indicates success or failure.
99.9% of the rows will have "0" in that column. But a small number will
have 1. I need to be able to fetch those rows quickly, without slowing
everything else do
11 matches
Mail list logo
