* Robert Haas (robertmh...@gmail.com) wrote: > I see that... but I don't think the test in the first loop is correct. > It's based on the value of i % 4, but I'm not convinced that you know > anything about the alignment at the point where i == 0.
Ah, you may be half right there (see below). It does appear to be assuming that char *s (or s[i == 0]) is aligned, which isn't a guarentee (in fact, it might never be right..). If having it actually aligned is an important bit (as opposed to just doing the comparisons in larger but possibly unaligned blocks) then that'd make a difference. If the code as-is showed performance improvment even when it's working on less-than-aligned blocks, I'd be curious what would happen if it was actually aligned. Unfortunately, the results of such would probably be heavily architecture dependent.. > > On the flip side, I am curious as to if the arguments to a stored > > procedure are always aligned or not. Never had a case to care before, > > but if palloc() is always going to return an aligned chunk of memory > > (per MemSetAligned in c.h) it makes me wonder. > > Well, if it's char(n) for n <~ 126, it's going to have a 1-byte > varlena header... Right, but I'm talking about the base of the argument itself, not the start of the data. If every variable length argument to a stored procedure is palloc()'d independently, and palloc()'s always return aligned memory, we'd at least know that the base of the argument is aligned and could figure out the header size and then do the comparisons accordingly. This would also mean, of course, that we'd almost(?) never have s[i == 0] on an aligned boundary due to the header. Thanks, Stephen
signature.asc
Description: Digital signature