Duncan Kinnear wrote:
> Bingo! Adding 'SET LOCAL synchronous_commit TO OFF;' to my 'BEGIN; UPDATE
> ; COMMIT;'
> block has given me sub-1ms timings! Thanks Andres.
That's a pretty clear indication that your I/O subsystem was overloaded.
Yours,
Laurenz Albe
--
Cybertec |
- On 10 Apr, 2019, at 10:23 AM, Andres Freund and...@anarazel.de wrote:
> On 2019-04-09 17:12:27 -0500, Justin Pryzby wrote:
>> You could test that's the issue by comparing with fsync=off (please read what
>> that means and don't run your production cluster like that).
>>
Hi,
On 2019-04-09 17:12:27 -0500, Justin Pryzby wrote:
> You could test that's the issue by comparing with fsync=off (please read what
> that means and don't run your production cluster like that).
> https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-FSYNC
I suggest testing it
On Wed, Apr 10, 2019 at 09:26:22AM +1200, Duncan Kinnear wrote:
> - On 5 Apr, 2019, at 4:14 AM, Jeff Janes wrote:
>
> > On Thu, Apr 4, 2019 at 3:42 AM Duncan Kinnear
> > wrote:
>
> >> the EXPLAIN (ANALYSE, TIMING TRUE) of this query gives:
>
> >> Update on next_id (cost=0.14..8.16
- On 5 Apr, 2019, at 4:14 AM, Jeff Janes wrote:
> On Thu, Apr 4, 2019 at 3:42 AM Duncan Kinnear < [
> mailto:duncan.kinn...@mccarthy.co.nz | duncan.kinn...@mccarthy.co.nz ] >
> wrote:
>> the EXPLAIN (ANALYSE, TIMING TRUE) of this query gives:
>> Update on next_id (cost=0.14..8.16 rows=1
On Thu, Apr 4, 2019 at 3:42 AM Duncan Kinnear
wrote:
>
> the EXPLAIN (ANALYSE, TIMING TRUE) of this query gives:
>
> Update on next_id (cost=0.14..8.16 rows=1 width=36) (actual
> time=0.057..0.057 rows=0 loops=1)
>-> Index Scan using next_id_pk on next_id (cost=0.14..8.16 rows=1
>
e same time on ALL of the servers -
approximately 1.7s - which makes sense as 10,000 times the above plan/execute
times is approx 1.7s.
So, to me this feels like some kind of COMMIT overhead of approx 50ms that the
version 10 and version 11 servers are experiencing. But I have no idea where to
