MySQL Forums
Forum List  »  Partitioning

Re: KEY vs RANGE partitioning
Posted by: Mattias Jonsson
Date: February 09, 2012 10:50AM


> >It will be done in a serial manner.
> Are you sure about that?

Yes :) (if you mean serial as the opposite of parallel. Otherwise it depends on the type of scan, table scan will be partition by partition, one after another. Index scans will start by picking the first matching row from each partition, then return the first through a priority queue, and filling up from the partition which the returned row came from. But there is no parallel scanning as in concurrency.)

> I read the manual but I
> did not find a clear answer on this. If this is
> true then I don't think that KEY partitioning is
> appropriate for me. RANGE is definitely my
> option.
> >What kind of queries do you do? only PK or mostly
> ranges? mostly selects/updated/inserts or deletes?
> I search with PK and I do almost only SELECTS.

If you only do SELECT by PK, then you will not gain anything with partitioning, unless your index is too big to fit into memory.

> The table contains the ID, 2 blobs and 1
> varchar(255).

Regards Mattias Jonsson, MySQL Partitioning developer.

Options: ReplyQuote

Written By
February 08, 2012 07:38AM
February 09, 2012 07:35AM
February 09, 2012 01:45AM
Re: KEY vs RANGE partitioning
February 09, 2012 10:50AM
February 09, 2012 04:22AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.