ClientRead

Perhaps I am misunderstanding something, but I am seeing a lot of ClientRead waits.

Above: A screenshot of AWS RDS Performance Insights.

If I am understanding this correctly, ClientRead is PostgreSQL server waiting for the client to submit to parameters, i.e. is this node-postgres taking its time to encode the parameters before sending them to the server?

Whats odd is that in case of the particular queries highlighted in the AWS RDS Performance Insights report, the input parameter is a single integer.

---

Might be unrelated to the above issue, but earlier I have observed that some queries are occasionally hanging in the ClientRead state, e.g.

applaudience=> SELECT
applaudience->   psa1.pid,
applaudience->   now() - psa1.query_start duration,
applaudience->   psa1.query,
applaudience->   psa1.*
applaudience-> FROM pg_stat_activity psa1
applaudience-> WHERE
applaudience->   psa1.state = 'active' AND
applaudience->   psa1.query_start < now() - interval '1 minute'
applaudience-> ORDER BY psa1.query_start ASC;
  pid   |    duration     |                                                                           query                                                                           | datid |   datname    |  pid   | usesysid | usename  |    application_name     |  client_addr   | client_hostname | client_port |         backend_start         |          xact_start           |          query_start          |         state_change          | wait_event_type | wait_event | state  | backend_xid | backend_xmin |                                                                           query                                                                           |  backend_type
--------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+-------+--------------+--------+----------+----------+-------------------------+----------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+-----------------+------------+--------+-------------+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+----------------
 107485 | 01:39:33.952415 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | 16390 | applaudience | 107485 |    16389 | postgres | data-management-program | 35.189.208.139 |                 |       43582 | 2018-11-26 18:01:57.283608+00 | 2018-11-26 18:05:04.010779+00 | 2018-11-26 18:05:04.011016+00 | 2018-11-26 18:05:04.011018+00 | Client          | ClientRead | active |             |    762082063 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | client backend
 107000 | 01:39:33.93314  | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | 16390 | applaudience | 107000 |    16389 | postgres | data-management-program | 35.189.208.139 |                 |       43400 | 2018-11-26 18:01:28.878422+00 | 2018-11-26 18:05:04.030169+00 | 2018-11-26 18:05:04.030291+00 | 2018-11-26 18:05:04.030292+00 | Client          | ClientRead | active |             |    762082063 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | client backend
 106686 | 01:39:33.853763 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | 16390 | applaudience | 106686 |    16389 | postgres | data-management-program | 35.195.228.15  |                 |       52444 | 2018-11-26 18:01:20.318759+00 | 2018-11-26 18:05:04.109547+00 | 2018-11-26 18:05:04.109668+00 | 2018-11-26 18:05:04.109669+00 | Client          | ClientRead | active |             |    762082063 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | client backend
 107439 | 01:39:33.560846 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | 16390 | applaudience | 107439 |    16389 | postgres | data-management-program | 35.189.208.139 |                 |       43554 | 2018-11-26 18:01:52.603207+00 | 2018-11-26 18:05:04.40246+00  | 2018-11-26 18:05:04.402585+00 | 2018-11-26 18:05:04.402586+00 | Client          | ClientRead | active |             |    762082063 | SELECT id, location_row "row", location_column "column", foreign_cinema_seat_type_id "foreignCinemaSeatTypeId", name FROM seat WHERE seating_plan_id = $1 | client backend
(4 rows)

Is anyone familiar with this?

[brianc]

Just a bit on how the driver / protocol work:

When you submit a query pg checks to see if it needs to be prepared:

https://github.com/brianc/node-postgres/blob/master/lib/query.js#L154

If the query needs preparation it results in a couple extra packets being sent:

First (usually) parse: https://github.com/brianc/node-postgres/blob/master/lib/query.js#L185 Then bind: https://github.com/brianc/node-postgres/blob/master/lib/query.js#L197 Then describe: https://github.com/brianc/node-postgres/blob/master/lib/query.js#L204 Execute: https://github.com/brianc/node-postgres/blob/master/lib/query.js#L171 And finally flush: https://github.com/brianc/node-postgres/blob/master/lib/query.js#L175

All these messages are written to a single buffer & pushed into the socket at once on the client-side of things. Looking I don’t see any place where significant latency would be introduced there…but, it definitely performs a lot more work than doing a non-parameterized query.

2 things you could try:

1. temporarily replace the query with a non-parameterized version - does the issue go away? Does overall query throughput increase significantly?
2. use a prepared statement - I don’t expect this to have big impact but would be worth a look, if you have time.

Lemme know if there’s anything in particular you want me to look at!

[ohjeyong]

For me, it is completely solved by upgrading to 8.5.1