postgresql and jdbc: striving for high performance

PostgreSQL and JDBC: striving for top performance

Vladimir SitnikovPgConf 2016

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

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

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();

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 -> 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

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

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

2.28 1.761.04 0.97

2000 rows

fetchSize

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:

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

- 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

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 (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), (?, ?, ?), ...;

Тестируемые запросы: 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

InsertBatchStructCopy

The number of inserted rows

int4, varchar, int4

COPY is good

16 128 10240

BatchStructCopy

The number of inserted rows

int4, varchar, int4

COPY is bad for small batches

1 4 8 16 12805

10152025

BatchStructCopy

Batch size in rows

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

Questions?

Vladimir Sitnikov,PgConf 2016

postgresql and jdbc: striving for high performance

Software

postgresql 9.0に対応！ powergresのご紹介€¦ ·...

informatica cloud & redshift user guide · pdf fileaccess to...

jdbc (@postgresql). dbi 2008 huji-cs 2 java database...

introduction to postgresql and jdbc - cs csu...

sopra-group jeizer systems solution · • suporta...

introduction to jdbc and jdbc drivers

Работа с базами данных – jdbc...

hybrid proof-of-concept for postgresql · postgresql...

introduction to jdbc - core web programming: course...

1 introduction to jdbc. 2 road map introduction to...

www.tutorialspoint.com jdbc jdbc tutorial

accessing databases with jdbc. introduction to jdbc jdbc...

how to install the postgresql jdbc driver - marco …...

08 java programming jdbc postgresql

linguaggio java jdbc - iet.unipi.it · connessione a: fonti...

jdbc–kurzeeinführung · typen von jdbc-treiber...

introduction to...

actuate birt java components developer...

Работа с базами данных – jdbc...

jdb c 컴퓨터정보과 안유정 교수 연구동 410 호...