Re: COMMIT NOWAIT Performance Option
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: COMMIT NOWAIT Performance Option |
Дата | |
Msg-id | 45E5A64F.8070601@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: COMMIT NOWAIT Performance Option (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
Gregory Stark wrote: > "Jonah H. Harris" <jonah.harris@gmail.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. yeah - on fast boxes (diskio wise) wal-crc checking is nearly always on the very top of wal-intensive workloads. Stefan
В списке pgsql-hackers по дате отправления: