Skip site navigation (1) Skip section navigation (2)

Re: TCP Overhead on Local Loopback

From: Dave Crooke <dcrooke(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Ofer Israeli <oferi(at)checkpoint(dot)com>, Samuel Gendler <sgendler(at)ideasculptor(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andy <angelflow(at)yahoo(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: TCP Overhead on Local Loopback
Date: 2012-04-03 16:04:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Tue, Apr 3, 2012 at 10:38 AM, Claudio Freire <klaussfreire(at)gmail(dot)com>wrote:

> You perform 8 roundtrips minimum per event, so that's 375us per query.
> It doesn't look like much. That's probably Nagle and task switching
> time, I don't think you can get it much lower than that, without
> issuing less queries (ie: using the COPY method).
I may be missing something stated earlier, but surely there are options in
between 7 individual statements and resorting to COPY and temp tables.

I'm thinking of a set of precompiled queries / prepared statements along
the lines of "SELECT FOR UPDATE WHERE foo in (?, ?, ?, .... ?)" that handle
e.g. 500-1000 records per invocation. Or what about a stored procedure that
updates one record, performing the necessary 7 steps, and then calling that
in bulk?

I agree with the assessment that 375us per statement is pretty decent, and
that going after the communication channel (TCP vs local pipe) is chasing
pennies when there are $100 bills lying around waiting to be collected.

In response to


pgsql-performance by date

Next:From: Kevin KempterDate: 2012-04-03 17:29:56
Subject: Update join performance issues
Previous:From: Cesar MartinDate: 2012-04-03 15:51:59
Subject: Re: H800 + md1200 Performance problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group