<p dir="ltr"><br /> On 9 May 2016 8:34 pm, "David Rowley" <<a
href="mailto:david.rowley@2ndquadrant.com">david.rowley@2ndquadrant.com</a>>wrote:<br /> ><br /> > This
projectdoes appear to require that we bloat the code with 100's<br /> > of vector versions of each function. I'm not
quitesure if there's a<br /> > better way to handle this. The problem is that the fmgr is pretty much<br /> > a
barrierto SIMD operations, and this was the only idea that I've had<br /> > so far about breaking through that
barrier.So further ideas here are<br /> > very welcome.<p dir="ltr">Well yes and no. In practice I think you only
needto worry about vectorised versions of integer and possibly float. For other data types there either aren't
vectorisedoperators or there's little using them.<p dir="ltr">And I'll make a bold claim here that the only operators I
thinkreally matter are =<p dir="ltr">The rain is because using SIMD instructions is a minor win if you have any further
workto 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 +
reallyonly would come up in odd examples.<p dir="ltr">But even that understates things. If you have column oriented
storagethen = becomes even more important since every scan has a series of implied equijoins to reconstruct the tuple.
Andthe coup de grace is that in a column oriented storage you try to store variable length data as integer indexes into
adictionary of common values so *everything* is an integer = operation.<p dir="ltr">How to do this without punching
rightthrough 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
tointeger indexes. But I'm not sure that's all that would be needed.