On Mon, Aug 8, 2016 at 10:03 AM, Bruce Momjian <br...@momjian.us> wrote: > On Mon, Aug 8, 2016 at 04:43:40PM +0530, Amit Kapila wrote: >> > According to developers, overhead is small, but many people have doubts >> > that it can be much more significant for intensive workloads. Obviously, it >> > is not an easy task to test, because you need to put doubtfully >> > non-production ready code into mission-critical production for such tests. >> > As a result it will be clear if this design should be abandoned and we >> > need to think about less-invasive solutions or this design is acceptable. >> > >> >> I think here main objection was that gettimeofday can cause >> performance regression which can be taken care by using configurable >> knob. I am not aware if any other part of the design has been >> discussed in detail to conclude whether it has any obvious problem. > > It seems asking users to run pg_test_timing before deploying to check > the overhead would be sufficient.
They should also run it in parallel, as sometimes the real overhead is in synchronization between multiple CPUs and doesn't show up when only a single CPU is involved. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
