Re: A common request

2011-03-31 Thread Gregory Magarshak
Thanks for your insight! But I'm still worried about the performance of IN ( big list of values ). Can you tell me how it is implemented? Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ..., 387945) 1) If I put 200 values there, does it do 200 individual SELECTs

Re: A common request

2011-03-31 Thread Gregory Magarshak
By the way, sorry ... I wanted to clarify one thing: I am trying to FILTER by the unique index (fb_uid) in this case, but JOIN on the primary key (id) and I don't need to use any other fields. I am guessing that the MySQL indexes map indexed fields (fb_uid) to the primary key (id) so I

Re: A common request

2011-03-31 Thread Johan De Meersman
- Original Message - From: Gregory Magarshak g...@qbix.com I am guessing that the MySQL indexes map indexed fields (fb_uid) to the primary key (id) so I wouldn't have to touch the disk. Am I right about that? Correct for InnoDB, but MyISAM maps every index straight onto records.

Re: A common request

2011-03-31 Thread mos
At 07:29 AM 3/31/2011, you wrote: Thanks for your insight! But I'm still worried about the performance of IN ( big list of values ). Can you tell me how it is implemented? Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ..., 387945) 1) If I put 200 values there, does it

Re: A common request

2011-03-31 Thread Johan De Meersman
- Original Message - From: mos mo...@fastmail.fm The IN() clause is very inefficient because MySQL will NOT use the index. It will have to traverse the entire table looking for these values. Has that still not been remedied ? It will get the information from the index and not

Re: A common request

2011-03-31 Thread mos
At 11:20 AM 3/31/2011, you wrote: At 07:29 AM 3/31/2011, you wrote: Thanks for your insight! But I'm still worried about the performance of IN ( big list of values ). Can you tell me how it is implemented? Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ..., 387945) 1)

Re: A common request

2011-03-31 Thread Wm Mussatto
On Thu, March 31, 2011 12:33, mos wrote: At 11:20 AM 3/31/2011, you wrote: At 07:29 AM 3/31/2011, you wrote: Thanks for your insight! But I'm still worried about the performance of IN ( big list of values ). Can you tell me how it is implemented? Suppose I have SELECT a FROM b WHERE c IN (1, 4,

A common request

2011-03-29 Thread Gregory Magarshak
Hey there. My company writes a lot of social applications, and there is one operation that is very common, but I don't know if MySQL supports it in a good way. I thought I'd write to this list for two reasons: 1) Maybe MySQL has a good way to do this, and I just don't know about it

Re: A common request

2011-03-29 Thread Peter Brawley
How can I quickly find all the articles written by this user's friends, and not just random articles? Taking the simplest possible case, with table friends(userID,friendID) where each friendID refers to a userID in another row, the friends of userID u are ... select friendID from user

Re: A common request

2011-03-29 Thread Gregory Magarshak
Yes, this would be fine. But often, the list of friends is obtained from a social network like facebook, and is not stored internally. Basically, I obtain the friend list in a request to facebook, and then see which of those users have created things. So would I have to create a temporary

Re: A common request

2011-03-29 Thread Peter Brawley
Why not optimize the IN ( ... ) to do the same type of thing? If the argument to IN() is a list of values, it'll be OK. If it's a SELECT, in 5.0 it will be slower than molasses (see The unbearable slowness of IN() at http://www.artfulsoftware.com/queries.php. I always tried to avoid joins

Re: A common request

2011-03-29 Thread Sander de Bruijne
Hi Gregory, Are you sure you'd like to do this using MySQL? What would happen if you start using sharding? Maybe you could consider using a stack (stored in a tool like Redis?). Whenever some user adds some item, you add primary key of the new item to the network updates stack of each