PostgreSQL and JDBC: striving for high performance

© 2016 NetCracker Technology Corporation Confidential
PostgreSQL and JDBC: striving for top performance
Vladimir Sitnikov
PgConf 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 query
https://github.com/pgjdbc/pgjdbc/pull/478
backend 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();

Smoker’s approach to PostgreSQL
PARSE S_1 as ...; // con.prepareStmt
BIND/EXEC
DEALLOCATE // ps.close()
PARSE S_2 as ...;
BIND/EXEC
DEALLOCATE // 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 statements
ps = 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
@Benchmark
public Statement leakStatement() {
return con.createStatement();
}
pgjdbc < 9.4.1202, -Xmx128m, OracleJDK 1.8u40
# Warmup Iteration 1: 1147,070 ns/op
# Warmup Iteration 4: <failure>
java.lang.OutOfMemoryError: GC overhead limit
exceeded

Unclosed statements in practice
@Benchmark
public Statement leakStatement() {
return con.createStatement();
}
pgjdbc >= 9.4.1202, -Xmx128m, OracleJDK 1.8u40
# Warmup Iteration 1: 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 statement
ps.setInt(1, 42);
...
ps.setNull(1, Types.VARCHAR);

Parameter types
If the type of bind value changes, you have to
recreate server-prepared statement
ps.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. Feature
B. 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

0.1ms  1st execution
0.05ms  2nd execution
0.05ms  3rd execution
0.05ms  4th execution
250 ms  6th execution

0.1ms  1st execution
0.05ms  2nd execution
0.05ms  3rd 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

We just use +0 to forbid index on a bad column
select *
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); -- 1ms
explain 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. Error
B.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
6.48
2.28
1.76
1.04 0.97
0
2
4
6
8
10 50 100 1000 2000
Faster,ms
fetchSize
2000 rows
2000 rows
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/EXEC
SYNC  flush & wait for the response
BIND/EXEC
BIND/EXEC
SYNC  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(?, ?, ?)

values(?, ?, ?)

values (?, ?, ?), (?, ?, ?), (?, ?,
?), (?, ?, ?), (?, ?, ?), (?, ?, ?),
(?, ?, ?), (?, ?, ?), (?, ?, ?), ...;

Тестируемые запросы: COPY
COPY batch_perf_test FROM STDIN
1 s1 1
2 s2 2
3 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.
2
16
128
0
50
100
150
16 128 1024
faster,ms
The number of inserted rows
Insert
Batch
Struct
Copy
int4, varchar, int4

COPY is good
0
0.5
1
1.5
2
2.5
16 128 1024
Faster,ms
The number of inserted rows
Batch
Struct
Copy
int4, varchar, int4

COPY is bad for small batches
0
5
10
15
20
25
1 4 8 16 128
Faster,ms
Batch size in rows
Batch
Struct
Copy
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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie PostgreSQL and JDBC: striving for high performance

Ähnlich wie PostgreSQL and JDBC: striving for high performance (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

PostgreSQL and JDBC: striving for high performance