Hi, On 2017-03-14 20:28:51 +0200, Heikki Linnakangas wrote: > On 03/14/2017 07:31 PM, Andres Freund wrote: > > On 2017-03-14 16:58:54 +0200, Heikki Linnakangas wrote: > > > * How tight are we on space in the ExprEvalStep union? Currently, the > > > jump-threading preparation replaces the opcodes with the goto labels, but > > > it > > > would be really nice to keep the original opcodes, for debugging purposes > > > if > > > nothing else. > > > > There's nothing left to spare :(. For debugging I've just used > > ExecEvalStepOp() - it's inconvenient to directly print the struct > > anyway, since gdb prints the whole union... > > This comment above the union is not accurate: > > > /* > > * Data for an operation. Inline stored data is faster to access, but > > also > > * bloats the size of all instructions. The union should be kept below > > 48 > > * bytes (so the entire struct is below 64bytes, a single cacheline on > > * common systems). > > */ > > On my x86-64 system, the whole struct is 64 bytes, but the union is only 40 > bytes. The fields before the union occupy 24 bytes. IOW, the union should be > kept below 40 bytes, not 48.
Point. Will update. > Hmm. Could we make the instructions variable size? It would allow packing > the small instructions even more tight, and we wouldn't need to obsess over > a particular maximum size for more complicated instructions. That makes jumps a lot more complicated. I'd experimented with it and given it up as "not worth it". If we were to try to do so, we'd also not like storing the pointer and enum variants both, since it'd again would reduce the density. > A compromise might be to have the fixed size, but have "continuation" > opcodes for the more complicated instructions. An XmlExpr instruction, for > example, could have an extra instruction after the primary one, just to hold > more fields. When evaluating it, we would just increment the Program Counter > by two instead of one, to skip over the extra instruction. I think for cases where 40 bytes becomes the limit, it's usually better to have out-of-line state. We could do this, but we'd also waste a bunch of space in the array (namely the 24 byte Op "header"). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
