The real answer, yes. It has a limit of several GB, depending on your OS.
It can take a huge string containing MBytes of BLOB data.
Just for grins, I loaded several MB of image data this way just to prove to
myself that you could do it.
The practical answer is then pretty much no. (Probably wo
Steve Meyers wrote:
> In a previous message, I failed to mention one of the main reasons you
> would NOT want to use a 500-character primary key. MySQL uses a key
> buffer to keep as much index information in memory as possible. The
> longer the key, the less info it can keep in memory, and
In the last episode (Oct 23), Jeremy Zawodny said:
> On Mon, Oct 22, 2001 at 11:42:23AM -0600, Steve Meyers wrote:
> > If you use a good 64-bit hash, I doubt you'll run into any
> > uniqueness problems. MySQL will support that as a 64-bit BIGINT.
> > You especially should not have any problems if
On 23-Oct-2001 Steve Meyers wrote:
>> > At a previous job, we tested a 32-bit hash function by running it
>> > against hundreds of thousands of unique URL's stored in our
>> > database. We found one collision. A 64-bit hash is billions of
>> > times better (4 billion, to be exact).
>>
>> Good
> I am not understanding why having a hash and the full url in the
> database would not take care of the collisions. Even if you had
> 10 collisions for a 16 bit hash (say), if your query was:
> SELECT ... WHERE hash=thehashvalue AND url='theurl' you would get
> very fast lookups on the hash a
Hi!
I changed now ha_innobase.h so that InnoDB allows
keys up to 7000 bytes in length. The change will be
in MySQL-3.23.44 and 4.0.1.
Regards,
Heikki
http://www.innodb.com
>Steve Meyers wrote:
>
>> > > At a previous job, we tested a 32-bit hash function by running it
>> > > against hundreds of
Steve Meyers wrote:
> > > At a previous job, we tested a 32-bit hash function by running it
> > > against hundreds of thousands of unique URL's stored in our
> > > database. We found one collision. A 64-bit hash is billions of
> > > times better (4 billion, to be exact).
> >
> > Good to know.
> > At a previous job, we tested a 32-bit hash function by running it
> > against hundreds of thousands of unique URL's stored in our
> > database. We found one collision. A 64-bit hash is billions of
> > times better (4 billion, to be exact).
>
> Good to know. I wonder how many collisions I'd
> > At a previous job, we tested a 32-bit hash function by running it
> > against hundreds of thousands of unique URL's stored in our
> > database. We found one collision. A 64-bit hash is billions of
> > times better (4 billion, to be exact).
>
> Good to know. I wonder how many collisions I'd
On Mon, Oct 22, 2001 at 11:42:23AM -0600, Steve Meyers wrote:
>
> If you use a good 64-bit hash, I doubt you'll run into any
> uniqueness problems. MySQL will support that as a 64-bit BIGINT.
> You especially should not have any problems if you hash each column,
> then do the primary key across
> > The problem is that he has it as a primary key, so he wants it to be
>
> > unique as well as indexed. The best solution (and MUCH MUCH MUCH
>
> > more efficient) would be to hash each of the four columns, and create
> > a primary key on that. Integer keys are much faster and memory-
>
Steve Meyers wrote:
> The problem is that he has it as a primary key, so he wants it to be
> unique as well as indexed. The best solution (and MUCH MUCH MUCH
> more efficient) would be to hash each of the four columns, and create
> a primary key on that. Integer keys are much faster and me
keys.
Steve Meyers
> -Original Message-
> From: Chris Bolt [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, October 20, 2001 8:31 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Length limit of 500 on primary keys?
>
>
> > Is there a way to raise this limit? We have some
> Is there a way to raise this limit? We have some tables with columns that
> are VARCHAR(200), and need to make a primary key based on combinations of
> these columns (in some cases, upto 4 columns), and MySQL complains for all
> of these table definitions that "Specified key was too long. Max ke
14 matches
Mail list logo
