Re: Raw device I/O for large objects

Hi,

Georgi Chulkov wrote:
> Please allow me to ask then:
> 1. In your opinion, would the above scenario indeed benefit from a raw-device 
> interface for large objects?

No, because file systems also try to do what you outline above. They 
certainly don't split sequential data up into blocks and distribute them 
randomly over the device, at least not without having a pretty good 
reason to do so (with which you'd also have to fight).

The possible gain achievable is pretty minimal, especially in 
conjunction with a (hopefully battery backed) write cache.

> 2. How feasible it is to decouple general table storage from large object 
> storage?

I think that would be the easiest part. I would go for a pluggable 
storage implementation, selectable per tablespace. But then again, I 
wouldn't do it at all. After all, this is what MySQL is doing. And we 
certainly don't want to repeat their mistakes! Or do you know anybody 
who goes like: "Yepee, multiple storages engines to choose from for my 
(un)valuable data, lets put some here and others there...".

Let's optimize the *one* storage engine we have and try to make that 
work well together with the various filesystems it uses. Because 
filesystems are already very good in what they are used for. (And we are 
glad we can use a filesystem and don't need to implement one ourselves).

Regards

Markus