Re: COMMIT NOWAIT Performance Option

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:

> This proposed design is overcomplicated and a waste of space. I mean,
> we reduce storage overhead using phantom command id and variable
> varlena, but let's just fill it up again with unnecessary junk bytes.

We reduced storage overhead using phantom command id by 8 bytes *per tuple*. I
hardly think 8 bytes per page is much of a concern. You're already losing an
average of 1/2 a tuple per page to rounding and that's a minimum of 16 bytes
for the narrowest of tuples.

>> That seems pretty unlikely. CRC checks are expensive cpu-wise, we're already
>> suffering a copy due to our use of read/write the difference between
>> read/write of 8192 bytes and readv/writev of 511b*16+1*6 is going to be
>> non-zero but very small. Thousands of times quicker than the CRC.
>
> Prove it.

We've already seen wal CRC checking show up at the top of profiles.

Do you really doubt that memcpy is faster than CRC32 checking? Especially when
you're already doing memcpy anyways and the only overhead is the few unaligned
bytes at the end and the 8 one-byte copies?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com