On 9 May 2016 8:34 pm, "David Rowley" <david.row...@2ndquadrant.com> wrote: > > This project does appear to require that we bloat the code with 100's > of vector versions of each function. I'm not quite sure if there's a > better way to handle this. The problem is that the fmgr is pretty much > a barrier to SIMD operations, and this was the only idea that I've had > so far about breaking through that barrier. So further ideas here are > very welcome.
Well yes and no. In practice I think you only need to worry about vectorised versions of integer and possibly float. For other data types there either aren't vectorised operators or there's little using them. And I'll make a bold claim here that the only operators I think really matter are = The rain is because using SIMD instructions is a minor win if you have any further work to do per tuple. The only time it's a big win is if you're eliminating entire tuples from consideration efficiently. = is going to do that often, other btree operator classes might be somewhat useful, but things like + really only would come up in odd examples. But even that understates things. If you have column oriented storage then = becomes even more important since every scan has a series of implied equijoins to reconstruct the tuple. And the coup de grace is that in a column oriented storage you try to store variable length data as integer indexes into a dictionary of common values so *everything* is an integer = operation. How to do this without punching right through the executor as an abstraction and still supporting extensible data types and operators was puzzling me already. I do think it involves having these vector operators in the catalogue and also some kind of compression mapping to integer indexes. But I'm not sure that's all that would be needed.
