I’m looking to use fadvise for an opposite example: I need to set FADV_NOREUSE for block-device backups since it is pointless to cache a sequential block-device read when it will only be read once.

In this case, I am using the rdiff to replicate LVM snapshots, and was thinking of writing an LD_PRELOAD wrapper for open() and fadvising the resulting file descriptor instead of hacking the rdiff code.

Since you have dug into the depths of fadvise, do you you have any advice here?

-Eric

Sometimes it’s not *two* queries one would have to issue, but rather 10,000 queries. So it is definitely not a rule of thumb, in my opinion, to prefer non-GROUP_CONCAT queries.

Perhaps not in the specific case you have presented, but generally speaking, and assuming people set their group_concat_max_len param to a reasonable value (and the default is terribly low), I do recommend getting the hang of it.

although I agree there is a lot not to like about GROUP_CONCAT, I find it a very useful tool if used right. There’s one thing that I found a but puzzling in your post:

“the application that was using group_concat was just parsing the result back into an array anyway. … This is what I recommend for fixing group_concat. The risk of having truncated values or running out of memory is too much to justify saving the cost of issuing a second query.”

Wouldn’t this just mean you’d run out of memory when you try to create the array? I mean, whether the memory is in a string or in an array, the bytes have to be in memory somewhere, no?

(BTW, I absolutely agree the truncation is a bad thing, that should be an error. And I think GROUP_CONCAT should get a LIMIT clause, not to prevent truncation but there are cases where one could use that to make queries more efficient and less memory intensive)