postgresql and jdbc: striving for high performance

© 2016 NetCracker Technology Corporation Confidential

PostgreSQL and JDBC: striving for top performance

Vladimir SitnikovPgConf 2016

2© 2016 NetCracker Technology Corporation Confidential

About me

• Vladimir Sitnikov, @VladimirSitnikv• Performance architect at NetCracker• 10 years of experience with Java/SQL• PgJDBC committer


Explain (analyze, buffers) PostgreSQL and JDBC

•Data fetch•Data upload•Performance•Pitfalls


Intro

Fetch of a single row via primary key lookup takes 20ms. Localhost. Database is fully cached

A. Just fine C. Kidding? Aim is 1ms!B. It should be 1sec D. 100us


Lots of small queries is a problem

Suppose a single query takes 10ms, then 100 of them would take a whole second *

* Your Captain


PostgreSQL frontend-backend protocol

• Simple query• 'Q' + length + query_text•Extended query•Parse, Bind, Execute commands



Super extended queryhttps://github.com/pgjdbc/pgjdbc/pull/478backend protocol wanted features

https://github.com/pgjdbc/pgjdbc/pull/478





Simple query•Works well for one-time queries•Does not support binary transfer



Extended query• Eliminates planning time• Supports binary transfer


PreparedStatement

Connection con = ...;PreparedStatement ps = con.prepareStatement("SELECT..."); ...ps.close();


Smoker’s approach to PostgreSQL

PARSE S_1 as ...; // con.prepareStmt BIND/EXECDEALLOCATE // ps.close()PARSE S_2 as ...; BIND/EXECDEALLOCATE // ps.close()


Healthy approach to PostgreSQL

PARSE S_1 as ...; BIND/EXEC BIND/EXEC BIND/EXEC BIND/EXEC BIND/EXEC ...DEALLOCATE


Healthy approach to PostgreSQL

PARSE S_1 as ...; 1 once in a life BIND/EXEC REST call BIND/EXEC BIND/EXEC one more REST call BIND/EXEC BIND/EXEC ...DEALLOCATE “never” is the best


Happiness closes no statements

Conclusion №1: in order to get top performance, you should not close statementsps = con.prepareStatement(...)ps.execueQuery();ps = con.prepareStatement(...)ps.execueQuery();...


Happiness closes no statements

Conclusion №1: in order to get top performance, you should not close statements

ps = con.prepare...ps.execueQuery();ps = con.prepare...ps.execueQuery();...


Unclosed statements in practice

@Benchmarkpublic Statement leakStatement() { return con.createStatement();}pgjdbc < 9.4.1202, -Xmx128m, OracleJDK 1.8u40# Warmup Iteration 1: 1147,070 ns/op# Warmup Iteration 2: 12101,537 ns/op# Warmup Iteration 3: 90825,971 ns/op# Warmup Iteration 4: <failure>java.lang.OutOfMemoryError: GC overhead limit exceeded


Unclosed statements in practice

@Benchmarkpublic Statement leakStatement() { return con.createStatement();}pgjdbc >= 9.4.1202, -Xmx128m, OracleJDK 1.8u40# Warmup Iteration 1: 30 ns/op# Warmup Iteration 2: 27 ns/op# Warmup Iteration 3: 30 ns/op...


Statements in practice

• In practice, application is always closing the statements• PostgreSQL has no shared query cache• Nobody wants spending excessive time on

planning


Server-prepared statements

What can we do about it?• Wrap all the queries in PL/PgSQL• It helps, however we had 100500 SQL of them

• Teach JDBC to cache queries


Query cache in PgJDBC

• Query cache was implemented in 9.4.1202 (2015-08-27)see https://github.com/pgjdbc/pgjdbc/pull/319• Is transparent to the application• We did not bother considering PL/PgSQL again• Server-prepare is activated after 5 executions

(prepareThreshold)





Where are the numbers?

• Of course, planning time depends on the query complexity• We observed 20мс+ planning time for OLTP

queries: 10KiB query, 170 lines explain• Result is ~0ms


Overheads


Generated queries are bad

• If a query is generated• It results in a brand new java.lang.String object• Thus you have to recompute its hashCode


Parameter types

If the type of bind value changes, you have to recreate server-prepared statementps.setInt(1, 42);...ps.setNull(1, Types.VARCHAR);


Parameter types

If the type of bind value changes, you have to recreate server-prepared statementps.setInt(1, 42);...ps.setNull(1, Types.VARCHAR);

It leads to DEALLOCATE PREPARE


Keep data type the same

Conclusion №1• Even NULL values should be properly typed


Unexpected degradation

If using prepared statements, the response time gets 5'000 times slower. How’s that possible?

A. Bug C. FeatureB. Feature D. Bug



https://gist.github.com/vlsi -> 01_plan_flipper.sql

select * from plan_flipper -- <- table where skewed = 0 -- 1M rows and non_skewed = 42 -- 20 rows

https://gist.github.com/vlsi/df08cbef370b2e86a5c1



https://gist.github.com/vlsi -> 01_plan_flipper.sql0.1ms 1st execution0.05ms 2nd execution0.05ms 3rd execution0.05ms 4th execution0.05ms 5th execution250 ms 6th execution




https://gist.github.com/vlsi -> 01_plan_flipper.sql0.1ms 1st execution0.05ms 2nd execution0.05ms 3rd execution0.05ms 4th execution0.05ms 5th execution

250 ms 6th execution




• Who is to blame?• PostgreSQL switches to generic plan after 5

executions of a server-prepared statement

• What can we do about it?• Add +0, OFFSET 0, and so on• Pay attention on plan validation• Discuss the phenomenon pgsql-hackers

http://www.postgresql.org/message-id/CAB=Je-G_oBsdrjWuPNsb0jcQ9X1A9jygCnKZW2izejoYG5YoeA@mail.gmail.com



https://gist.github.com/vlsi -> 01_plan_flipper.sqlWe just use +0 to forbid index on a bad columnselect * from plan_flipper where skewed+0 = 0 ~ /*+no_index*/ and non_skewed = 42



Explain explain explain explain

The rule of 6 explains:prepare x(number) as select ...;explain analyze execute x(42); -- 1msexplain analyze execute x(42); -- 1msexplain analyze execute x(42); -- 1msexplain analyze execute x(42); -- 1msexplain analyze execute x(42); -- 1msexplain analyze execute x(42); -- 10 sec


Везде баг


Decision problem

There’s a schema A with table X, and a schema B with table X. What is the result of select * from X?

A.X C. ErrorB.X D. All of the above


Search_path

There’s a schema A with table X, and a schema B with table X. What is the result of select * from X?• search_path determines the schema used• server-prepared statements are not prepared for

search_path changes crazy things might happen


Search_path can go wrong

• 9.1 will just use old OIDs and execute the “previous” query• 9.2-9.5 might fail with "cached plan must not change

result type” error


Search_path

What can we do about it?• Keep search_path constant• Discuss it in pgsql-hackers• Set search_path

+ server-prepared statements = cached plan must not change result type

• PL/pgSQL has exactly the same issue

http://www.postgresql.org/message-id/CAB=Je-GQOW7kU9Hn3AqP1vhaZg_wE9Lz6F4jSp-7cm9_M6DyVA@mail.gmail.com






To fetch or not to fetch

You are to fetch 1M rows 1KiB each, -Xmx128m while (resultSet.next()) resultSet.getString(1);

A. No problem C. Must use LIMIT/OFFSET

B. OutOfMemory D. autoCommit(false)


To fetch or not to fetch

• PgJDBC fetches all rows by default• To fetch in batches, you need Statement.setFetchSize and connection.setAutoCommit(false)• Default value is configurable via defaultRowFetchSize (9.4.1202+)


fetchSize vs fetch time

10 50 100 1000 200002468

6.48

2.28 1.761.04 0.97

2000 rows

2000 rows

fetchSize

Fa

ster

, ms

select int4, int4, int4, int4


FetchSize is good for stability

Conclusion №2:• For stability & performance reasons set defaultRowFetchSize >= 100


Data upload

For data uploads, use• INSERT() VALUES()• INSERT() SELECT ?, ?, ?• INSERT() VALUES() executeBatch• INSERT() VALUES(), (), () executeBatch• COPY


Healty batch INSERT

PARSE S_1 as ...; BIND/EXEC BIND/EXEC BIND/EXEC BIND/EXEC BIND/EXEC ...DEALLOCATE


TCP strikes back

JDBC is busy with sending queries, thus it has not started

fetching responses yet

DB cannot fetch more queries since it is busy with sending responses


Batch INSERT in real life

PARSE S_1 as ...; BIND/EXEC BIND/EXECSYNC flush & wait for the response BIND/EXEC BIND/EXECSYNC flush & wait for the response ...


TCP deadlock avoidance

• PgJDBC adds SYNC to your nice batch operations• The more the SYNCs the slower it performs


Horror stories

A single line patch makes insert batch 10 times faster:


- static int QUERY_FORCE_DESCRIBE_PORTAL = 128;+ static int QUERY_FORCE_DESCRIBE_PORTAL = 512;...// 128 has already been used static int QUERY_DISALLOW_BATCHING = 128;





Trust but always measure

• Java 1.8u40+• Core i7 2.6Ghz• Java microbenchmark harness• PostgreSQL 9.5

http://openjdk.java.net/projects/code-tools/jmh/




Queries under test: INSERT

pgjdbc/ubenchmark/InsertBatch.java

insert into batch_perf_test(a, b, c) values(?, ?, ?)




insert into batch_perf_test(a, b, c) values(?, ?, ?)




insert into batch_perf_test(a, b, c) values (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), ...;


Тестируемые запросы: COPY


COPY batch_perf_test FROM STDIN1 s1 12 s2 23 s3 3...


Queries under test: hand-made structs


insert into batch_perf_test select * from unnest('{"(1,s1,1)","(2,s2,2)", "(3,s3,3)"}'::batch_perf_test[])


You’d better use batch, your C.O.

16 128 10240

50

100

150

216

128

InsertBatchStructCopy

The number of inserted rows

fa

ster

, ms

int4, varchar, int4


COPY is good

16 128 10240

0.51

1.52

2.5

BatchStructCopy

The number of inserted rows

Fa

ster

, ms

int4, varchar, int4


COPY is bad for small batches

1 4 8 16 12805

10152025

BatchStructCopy

Batch size in rows

Fa

ster

, ms

Insert of 1024 rows


Final thoughts

• PreparedStatement is our hero• Remember to EXPLAIN ANALYZE at least six

times, a blue moon is a plus• Don’t forget +0 and OFFSET 0


About me

• Vladimir Sitnikov, @VladimirSitnikv• Performance architect in NetCracker• 10 years of experience with Java/SQL• PgJDBC committer

postgresql and jdbc: striving for high performance

Software