Very slow Query compared to Oracle / SQL - Server

From: Semen Yefimenko <semen(dot)yefimenko(at)gmail(dot)com>
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Very slow Query compared to Oracle / SQL - Server
Date: 2021-05-06 14:38:39
Message-ID: CAKnyMoKUUSPiH=0QaM38GYm8UqVeR47HmX+MX+UpyL0mLERBrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi there,

I've recently been involved in migrating our old system to SQL Server and
then PostgreSQL. Everything has been working fine so far but now after
executing our tests on Postgres, we saw a very slow running query on a
large table in our database.
I have tried asking on other platforms but no one has been able to give me
a satisfying answer.

*Postgres Version : *PostgreSQL 12.2, compiled by Visual C++ build 1914,
64-bit
No notable errors in the Server log and the Postgres Server itself.

The table structure :

CREATE TABLE logtable
(
key character varying(20) COLLATE pg_catalog."default" NOT NULL,
id integer,
column3 integer,
column4 integer,
column5 integer,
column6 integer,
column7 integer,
column8 integer,
column9 character varying(128) COLLATE pg_catalog."default",
column10 character varying(2048) COLLATE pg_catalog."default",
column11 character varying(2048) COLLATE pg_catalog."default",
column12 character varying(2048) COLLATE pg_catalog."default",
column13 character varying(2048) COLLATE pg_catalog."default",
column14 character varying(2048) COLLATE pg_catalog."default",
column15 character varying(2048) COLLATE pg_catalog."default",
column16 character varying(2048) COLLATE pg_catalog."default",
column17 character varying(2048) COLLATE pg_catalog."default",
column18 character varying(2048) COLLATE pg_catalog."default",
column19 character varying(2048) COLLATE pg_catalog."default",
column21 character varying(256) COLLATE pg_catalog."default",
column22 character varying(256) COLLATE pg_catalog."default",
column23 character varying(256) COLLATE pg_catalog."default",
column24 character varying(256) COLLATE pg_catalog."default",
column25 character varying(256) COLLATE pg_catalog."default",
column26 character varying(256) COLLATE pg_catalog."default",
column27 character varying(256) COLLATE pg_catalog."default",
column28 character varying(256) COLLATE pg_catalog."default",
column29 character varying(256) COLLATE pg_catalog."default",
column30 character varying(256) COLLATE pg_catalog."default",
column31 character varying(256) COLLATE pg_catalog."default",
column32 character varying(256) COLLATE pg_catalog."default",
column33 character varying(256) COLLATE pg_catalog."default",
column34 character varying(256) COLLATE pg_catalog."default",
column35 character varying(256) COLLATE pg_catalog."default",
entrytype integer,
column37 bigint,
column38 bigint,
column39 bigint,
column40 bigint,
column41 bigint,
column42 bigint,
column43 bigint,
column44 bigint,
column45 bigint,
column46 bigint,
column47 character varying(128) COLLATE pg_catalog."default",
timestampcol timestamp without time zone,
column49 timestamp without time zone,
column50 timestamp without time zone,
column51 timestamp without time zone,
column52 timestamp without time zone,
archivestatus integer,
column54 integer,
column55 character varying(20) COLLATE pg_catalog."default",
CONSTRAINT pkey PRIMARY KEY (key)
USING INDEX TABLESPACE tablespace
)

TABLESPACE tablespace;

ALTER TABLE schema.logtable
OWNER to user;

CREATE INDEX idx_timestampcol
ON schema.logtable USING btree
( timestampcol ASC NULLS LAST )
TABLESPACE tablespace ;

CREATE INDEX idx_test2
ON schema.logtable USING btree
( entrytype ASC NULLS LAST)
TABLESPACE tablespace
WHERE archivestatus <= 1;

CREATE INDEX idx_arcstatus
ON schema.logtable USING btree
( archivestatus ASC NULLS LAST)
TABLESPACE tablespace;

CREATE INDEX idx_entrytype
ON schema.logtable USING btree
( entrytype ASC NULLS LAST)
TABLESPACE tablespace ;

The table contains 14.000.000 entries and has about 3.3 GB of data:
No triggers, inserts per day, probably 5-20 K per day.

SELECT relname, relpages, reltuples, relallvisible, relkind, relnatts,
relhassubclass, reloptions, pg_table_size(oid) FROM pg_class WHERE
relname='logtable';

relname
|relpages|reltuples|relallvisible|relkind|relnatts|relhassubclass|reloptions|pg_table_size|
------------------|--------|---------|-------------|-------|--------|--------------|----------|-------------|
logtable | 405988| 14091424| 405907|r | 54|false
|NULL | 3326803968|

The slow running query:

SELECT column1,..., column54 where ((entrytype = 4000 or entrytype = 4001
or entrytype = 4002) and (archivestatus <= 1)) order by timestampcol desc;

This query runs in about 45-60 seconds.
The same query runs in about 289 ms Oracle and 423 ms in SQL-Server.
Now I understand that actually loading all results would take a while.
(about 520K or so rows)
But that shouldn't be exactly what happens right? There should be a
resultset iterator which can retrieve all data but doesn't from the get go.

With the help of some people in the slack and so thread, I've found a
configuration parameter which helps performance :

set random_page_cost = 1;

This improved performance from 45-60 s to 15-35 s. (since we are using
ssd's)
Still not acceptable but definitely an improvement.
Some maybe relevant system parameters:

effective_cache_size 4GB
maintenance_work_mem 1GB
shared_buffers 2GB
work_mem 1GB

Currently I'm accessing the data through DbBeaver (JDBC -
postgresql-42.2.5.jar) and our JAVA application (JDBC -
postgresql-42.2.19.jar). Both use the defaultRowFetchSize=5000 to not load
everything into memory and limit the results.
The explain plan:

EXPLAIN (ANALYZE, BUFFERS, SETTINGS, VERBOSE)...
(Above Query)

Gather Merge (cost=347142.71..397196.91 rows=429006 width=2558) (actual
time=21210.019..22319.444 rows=515841 loops=1)
Output: column1, .. , column54
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=141487 read=153489
-> Sort (cost=346142.69..346678.95 rows=214503 width=2558) (actual
time=21148.887..21297.428 rows=171947 loops=3)
Output: column1, .. , column54
Sort Key: logtable.timestampcol DESC
Sort Method: quicksort Memory: 62180kB
Worker 0: Sort Method: quicksort Memory: 56969kB
Worker 1: Sort Method: quicksort Memory: 56837kB
Buffers: shared hit=141487 read=153489
Worker 0: actual time=21129.973..21296.839 rows=166776 loops=1
Buffers: shared hit=45558 read=49514
Worker 1: actual time=21114.439..21268.117 rows=165896 loops=1
Buffers: shared hit=45104 read=49506
-> Parallel Bitmap Heap Scan on schema.logtable
(cost=5652.74..327147.77 rows=214503 width=2558) (actual
time=1304.813..20637.462 rows=171947 loops=3)
Output: column1, .. , column54
Recheck Cond: ((logtable.entrytype = 4000) OR
(logtable.entrytype = 4001) OR (logtable.entrytype = 4002))
Filter: (logtable.archivestatus <= 1)
Heap Blocks: exact=103962
Buffers: shared hit=141473 read=153489
Worker 0: actual time=1280.472..20638.620 rows=166776 loops=1
Buffers: shared hit=45551 read=49514
Worker 1: actual time=1275.274..20626.219 rows=165896 loops=1
Buffers: shared hit=45097 read=49506
-> BitmapOr (cost=5652.74..5652.74 rows=520443 width=0)
(actual time=1179.438..1179.438 rows=0 loops=1)
Buffers: shared hit=9 read=1323
-> Bitmap Index Scan on idx_entrytype
(cost=0.00..556.61 rows=54957 width=0) (actual time=161.939..161.940
rows=65970 loops=1)
Index Cond: (logtable.entrytype = 4000)
Buffers: shared hit=1 read=171
-> Bitmap Index Scan on idx_entrytype
(cost=0.00..2243.22 rows=221705 width=0) (actual time=548.849..548.849
rows=224945 loops=1)
Index Cond: (logtable.entrytype = 4001)
Buffers: shared hit=4 read=576
-> Bitmap Index Scan on idx_entrytype
(cost=0.00..2466.80 rows=243782 width=0) (actual time=468.637..468.637
rows=224926 loops=1)
Index Cond: (logtable.entrytype = 4002)
Buffers: shared hit=4 read=576
Settings: random_page_cost = '1', search_path = '"$user", schema, public',
temp_buffers = '80MB', work_mem = '1GB'
Planning Time: 0.578 ms
Execution Time: 22617.351 ms

As mentioned before, oracle does this much faster.

-------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name |
Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
6878 | 2491K| | 2143 (1)| 00:00:01 |
| 1 | SORT ORDER BY | |
6878 | 2491K| 3448K| 2143 (1)| 00:00:01 |
| 2 | INLIST ITERATOR | |
| | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID BATCHED| logtable |
6878 | 2491K| | 1597 (1)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | idx_entrytype |
6878 | | | 23 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------

Is there much I can analyze, any information you might need to further
analyze this?

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message luis.roberto 2021-05-06 16:11:07 Re: Very slow Query compared to Oracle / SQL - Server
Previous Message Alex 2021-05-05 15:21:30 Re: 15x slower PreparedStatement vs raw query