For testing purposes I set up a separate postgres 13.2 instance on windows.
To my surprise, it works perfectly fine. Also indexes, have about 1/4 of the size they had on 12.6.
I'll try setting up a new 12.6 instance and see if I can reproduce anything.
This explain plan is on a SSD local postgres 13.2 instance with default settings and not setting random_page_cost.
Unfortunately I couldn't reproduce the issue. I loaded the data with a tool that I wrote a few months ago which basically independently from that database inserts data and creates sequences and indexes.
Query also finishes in like 70 ~ ms. Then I've tried pg_dump into a different database on the same dev database (where the slow query still exists). The performance is just as bad on this database and indexes are also all 300 MB big (whereas on my locally running instance they're at around 80 MB)
Now I'm trying to insert the data with the same tool I've used for my local installations on the remote dev database.
This will still take some time so I will update once I have this tested.
Seems like there is something skewed going on with the development database so far.
To my surprise, it works perfectly fine. Also indexes, have about 1/4 of the size they had on 12.6.
I'll try setting up a new 12.6 instance and see if I can reproduce anything.
This explain plan is on a SSD local postgres 13.2 instance with default settings and not setting random_page_cost.
Gather Merge (cost=19444.07..19874.60 rows=3690 width=2638) (actual time=41.633..60.538 rows=7087 loops=1)I've also installed a locally running 12.6 on windows.
Output: column1, .. ,column54
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=2123
-> Sort (cost=18444.05..18448.66 rows=1845 width=2638) (actual time=4.057..4.595 rows=2362 loops=3)
Output: column1, .. ,column54
Sort Key: logtable.timestampcol1 DESC
Sort Method: quicksort Memory: 3555kB
Buffers: shared hit=2123
Worker 0: actual time=0.076..0.077 rows=0 loops=1
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=7
Worker 1: actual time=0.090..0.091 rows=0 loops=1
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=7
-> Parallel Bitmap Heap Scan on schema.logtable (cost=61.84..16243.96 rows=1845 width=2638) (actual time=0.350..2.419 rows=2362 loops=3)
Output: column1, .. ,column54
Recheck Cond: ((logtable.entrytype = 4000) OR (logtable.entrytype = 4001) OR (logtable.entrytype = 4002))
Filter: (logtable.tfnlogent_archivestatus <= 1)
Heap Blocks: exact=2095
Buffers: shared hit=2109
Worker 0: actual time=0.030..0.030 rows=0 loops=1
Worker 1: actual time=0.035..0.036 rows=0 loops=1
-> BitmapOr (cost=61.84..61.84 rows=4428 width=0) (actual time=0.740..0.742 rows=0 loops=1)
Buffers: shared hit=14
-> Bitmap Index Scan on idx_entrytype (cost=0.00..19.50 rows=1476 width=0) (actual time=0.504..0.504 rows=5475 loops=1)
Index Cond: (logtable.entrytype = 4000)
Buffers: shared hit=7
-> Bitmap Index Scan on idx_entrytype (cost=0.00..19.50 rows=1476 width=0) (actual time=0.056..0.056 rows=830 loops=1)
Index Cond: (logtable.entrytype = 4001)
Buffers: shared hit=3
-> Bitmap Index Scan on idx_entrytype (cost=0.00..19.50 rows=1476 width=0) (actual time=0.178..0.179 rows=782 loops=1)
Index Cond: (logtable.entrytype = 4002)
Buffers: shared hit=4
Planning Time: 0.212 ms
Execution Time: 61.692 ms
Unfortunately I couldn't reproduce the issue. I loaded the data with a tool that I wrote a few months ago which basically independently from that database inserts data and creates sequences and indexes.
Query also finishes in like 70 ~ ms. Then I've tried pg_dump into a different database on the same dev database (where the slow query still exists). The performance is just as bad on this database and indexes are also all 300 MB big (whereas on my locally running instance they're at around 80 MB)
Now I'm trying to insert the data with the same tool I've used for my local installations on the remote dev database.
This will still take some time so I will update once I have this tested.
Seems like there is something skewed going on with the development database so far.
Am Fr., 7. Mai 2021 um 11:56 Uhr schrieb Vijaykumar Jain <vijaykumarjain.github@xxxxxxxxx>:
Is this on windows ?I see a thread that mentions of performance penalty due to parallel workerThere is a mailing thread with subject line -Huge performance penalty with parallel queries in Windows x64 v. Linux x64--On Fri, 7 May 2021 at 2:33 PM Semen Yefimenko <semen.yefimenko@xxxxxxxxx> wrote:As mentionend in the slack comments :SELECT pg_size_pretty(pg_relation_size('logtable')) as table_size, pg_size_pretty(pg_relation_size('idx_entrytype')) as index_size, (pgstattuple('logtable')).dead_tuple_percent;table_size | index_size | dead_tuple_percentI have roughly 6 indexes which all have around 300 MB
------------+------------+--------------------
3177 MB | 289 MB | 0SELECT pg_relation_size('logtable') as table_size, pg_relation_size(idx_entrytype) as index_size, 100-(pgstatindex('idx_entrytype')).avg_leaf_density as bloat_ratiotable_size | index_size | bloat_ratioYour queries:
------------+------------+-------------------
3331694592 | 302555136 | 5.219999999999999n_live_tup n_dead_tup14118380 0
For testing, I've also been running VACUUM and ANALYZE pretty much before every test run.Am Fr., 7. Mai 2021 um 10:44 Uhr schrieb Vijaykumar Jain <vijaykumarjain.github@xxxxxxxxx>:ok one last thing, not to be a PITA, but just in case if this helps.postgres=# SELECT * FROM pg_stat_user_indexes where relname = 'logtable'; postgres=# SELECT * FROM pg_stat_user_tables where relname = 'logtable';basically, i just to verify if the table is not bloated.looking at n_live_tup vs n_dead_tup would help understand it.if you see too many dead tuples,vacuum (ANALYZE,verbose) logtable; -- would get rid of dead tuples (if there are no tx using the dead tuples)and then run your query.Thanks,VijayOn Fri, 7 May 2021 at 13:34, Semen Yefimenko <semen.yefimenko@xxxxxxxxx> wrote:Sorry if I'm cumulatively answering everyone in one E-Mail, I'm not sure how I'm supposed to do it. (single E-Mails vs many)
Can you try tuning by increasing the shared_buffers slowly in steps of 500MB, and running explain analyze against the query.
-- 2500 MB shared buffers - random_page_cost = 1;
Gather Merge (cost=343085.23..392186.19 rows=420836 width=2542) (actual time=2076.329..3737.050 rows=516517 loops=1)
Output: column1, .. , column54
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=295446
-> Sort (cost=342085.21..342611.25 rows=210418 width=2542) (actual time=2007.487..2202.707 rows=172172 loops=3)
Output: column1, .. , column54
Sort Key: logtable.timestampcol DESC
Sort Method: quicksort Memory: 65154kB
Worker 0: Sort Method: quicksort Memory: 55707kB
Worker 1: Sort Method: quicksort Memory: 55304kB
Buffers: shared hit=295446
Worker 0: actual time=1963.969..2156.624 rows=161205 loops=1
Buffers: shared hit=91028
Worker 1: actual time=1984.700..2179.697 rows=161935 loops=1
Buffers: shared hit=92133
-> Parallel Bitmap Heap Scan on schema.logtable (cost=5546.39..323481.21 rows=210418 width=2542) (actual time=322.125..1618.971 rows=172172 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=110951
Buffers: shared hit=295432
Worker 0: actual time=282.201..1595.117 rows=161205 loops=1
Buffers: shared hit=91021
Worker 1: actual time=303.671..1623.299 rows=161935 loops=1
Buffers: shared hit=92126
-> BitmapOr (cost=5546.39..5546.39 rows=510578 width=0) (actual time=199.119..199.119 rows=0 loops=1)
Buffers: shared hit=1334
-> Bitmap Index Scan on idx_entrytype (cost=0.00..682.13 rows=67293 width=0) (actual time=28.856..28.857 rows=65970 loops=1)
Index Cond: (logtable.entrytype = 4000)
Buffers: shared hit=172
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2223.63 rows=219760 width=0) (actual time=108.871..108.872 rows=225283 loops=1)
Index Cond: (logtable.entrytype = 4001)
Buffers: shared hit=581
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2261.87 rows=223525 width=0) (actual time=61.377..61.377 rows=225264 loops=1)
Index Cond: (logtable.entrytype = 4002)
Buffers: shared hit=581
Settings: random_page_cost = '1', temp_buffers = '80MB', work_mem = '1GB'
Planning Time: 0.940 ms
Execution Time: 4188.083 ms
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-- 3000 MB shared buffers - random_page_cost = 1;
Gather Merge (cost=343085.23..392186.19 rows=420836 width=2542) (actual time=2062.280..3763.408 rows=516517 loops=1)
Output: column1, .. , column54
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=295446
-> Sort (cost=342085.21..342611.25 rows=210418 width=2542) (actual time=1987.933..2180.422 rows=172172 loops=3)
Output: column1, .. , column54
Sort Key: logtable.timestampcol DESC
Sort Method: quicksort Memory: 66602kB
Worker 0: Sort Method: quicksort Memory: 55149kB
Worker 1: Sort Method: quicksort Memory: 54415kB
Buffers: shared hit=295446
Worker 0: actual time=1963.059..2147.916 rows=159556 loops=1
Buffers: shared hit=89981
Worker 1: actual time=1949.726..2136.200 rows=158554 loops=1
Buffers: shared hit=90141
-> Parallel Bitmap Heap Scan on schema.logtable (cost=5546.39..323481.21 rows=210418 width=2542) (actual time=340.705..1603.796 rows=172172 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=113990
Buffers: shared hit=295432
Worker 0: actual time=317.918..1605.548 rows=159556 loops=1
Buffers: shared hit=89974
Worker 1: actual time=304.744..1589.221 rows=158554 loops=1
Buffers: shared hit=90134
-> BitmapOr (cost=5546.39..5546.39 rows=510578 width=0) (actual time=218.972..218.973 rows=0 loops=1)
Buffers: shared hit=1334
-> Bitmap Index Scan on idx_entrytype (cost=0.00..682.13 rows=67293 width=0) (actual time=37.741..37.742 rows=65970 loops=1)
Index Cond: (logtable.entrytype = 4000)
Buffers: shared hit=172
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2223.63 rows=219760 width=0) (actual time=119.120..119.121 rows=225283 loops=1)
Index Cond: (logtable.entrytype = 4001)
Buffers: shared hit=581
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2261.87 rows=223525 width=0) (actual time=62.097..62.098 rows=225264 loops=1)
Index Cond: (logtable.entrytype = 4002)
Buffers: shared hit=581
Settings: random_page_cost = '1', temp_buffers = '80MB', work_mem = '1GB'
Planning Time: 2.717 ms
Execution Time: 4224.670 ms
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-- 3500 MB shared buffers - random_page_cost = 1;
Gather Merge (cost=343085.23..392186.19 rows=420836 width=2542) (actual time=3578.155..4932.858 rows=516517 loops=1)
Output: column1, .. , column54
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=14 read=295432 written=67
-> Sort (cost=342085.21..342611.25 rows=210418 width=2542) (actual time=3482.159..3677.227 rows=172172 loops=3)
Output: column1, .. , column54
Sort Key: logtable.timestampcol DESC
Sort Method: quicksort Memory: 58533kB
Worker 0: Sort Method: quicksort Memory: 56878kB
Worker 1: Sort Method: quicksort Memory: 60755kB
Buffers: shared hit=14 read=295432 written=67
Worker 0: actual time=3435.131..3632.985 rows=166842 loops=1
Buffers: shared hit=7 read=95783 written=25
Worker 1: actual time=3441.545..3649.345 rows=179354 loops=1
Buffers: shared hit=5 read=101608 written=20
-> Parallel Bitmap Heap Scan on schema.logtable (cost=5546.39..323481.21 rows=210418 width=2542) (actual time=345.111..3042.932 rows=172172 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=96709
Buffers: shared hit=2 read=295430 written=67
Worker 0: actual time=300.525..2999.403 rows=166842 loops=1
Buffers: shared read=95783 written=25
Worker 1: actual time=300.552..3004.859 rows=179354 loops=1
Buffers: shared read=101606 written=20
-> BitmapOr (cost=5546.39..5546.39 rows=510578 width=0) (actual time=241.996..241.997 rows=0 loops=1)
Buffers: shared hit=2 read=1332
-> Bitmap Index Scan on idx_entrytype (cost=0.00..682.13 rows=67293 width=0) (actual time=37.129..37.130 rows=65970 loops=1)
Index Cond: (logtable.entrytype = 4000)
Buffers: shared read=172
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2223.63 rows=219760 width=0) (actual time=131.051..131.052 rows=225283 loops=1)
Index Cond: (logtable.entrytype = 4001)
Buffers: shared hit=1 read=580
-> Bitmap Index Scan on idx_entrytype (cost=0.00..2261.87 rows=223525 width=0) (actual time=73.800..73.800 rows=225264 loops=1)
Index Cond: (logtable.entrytype = 4002)
Buffers: shared hit=1 read=580
Settings: random_page_cost = '1', temp_buffers = '80MB', work_mem = '1GB'
Planning Time: 0.597 ms
Execution Time: 5389.811 msThis doesn't seem to have had an effect.
Thanks for the suggestion.Have you try of excluding not null from index? Can you give dispersion of archivestatus?
Yes I have, it yielded the same performance boost as :create index test on logtable(entrytype) where archivestatus <= 1;I wonder what the old query plan was...
Would you include links to your prior correspondance ?
So prior Execution Plans are present in the SO.
The other forums I've tried are the official slack channel : https://postgresteam.slack.com/archives/C0FS3UTAP/p1620286295228600
And SO : https://stackoverflow.com/questions/67401792/slow-running-postgresql-query
But I think most of the points discussed in these posts have already been mentionend by you except bloating of indexes.Oracle is apparently doing a single scan on "entrytype".
As a test, you could try forcing that, like:
begin; SET enable_bitmapscan=off ; explain (analyze) [...]; rollback;
or
begin; DROP INDEX idx_arcstatus; explain (analyze) [...]; rollback;
I've tried enable_bitmapscan=off but it didn't yield any good results.-- 2000 MB shared buffers - random_page_cost = 4 - enable_bitmapscan to offGather Merge (cost=543949.72..593050.69 rows=420836 width=2542) (actual time=7716.031..9043.399 rows=516517 loops=1)Output: column1, .., column54Workers Planned: 2Workers Launched: 2Buffers: shared hit=192 read=406605-> Sort (cost=542949.70..543475.75 rows=210418 width=2542) (actual time=7642.666..7835.527 rows=172172 loops=3)Output: column1, .., column54Sort Key: logtable.timestampcol DESCSort Method: quicksort Memory: 58803kBWorker 0: Sort Method: quicksort Memory: 60376kBWorker 1: Sort Method: quicksort Memory: 56988kBBuffers: shared hit=192 read=406605Worker 0: actual time=7610.482..7814.905 rows=177637 loops=1Buffers: shared hit=78 read=137826Worker 1: actual time=7607.645..7803.561 rows=167316 loops=1Buffers: shared hit=80 read=132672-> Parallel Seq Scan on schema.logtable (cost=0.00..524345.70 rows=210418 width=2542) (actual time=1.669..7189.365 rows=172172 loops=3)Output: column1, .., column54Filter: ((logtable.acrhivestatus <= 1) AND ((logtable.entrytype = 4000) OR (logtable.entrytype = 4001) OR (logtable.entrytype = 4002)))Rows Removed by Filter: 4533459Buffers: shared hit=96 read=406605Worker 0: actual time=1.537..7158.286 rows=177637 loops=1Buffers: shared hit=30 read=137826Worker 1: actual time=1.414..7161.670 rows=167316 loops=1Buffers: shared hit=32 read=132672Settings: enable_bitmapscan = 'off', temp_buffers = '80MB', work_mem = '1GB'Planning Time: 0.725 msExecution Time: 9500.928 ms---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2000 MB shared buffers - random_page_cost = 4 - -- 2000 -- 2000 MB shared buffers - random_page_cost = 1 - enable_bitmapscan to offGather Merge (cost=543949.72..593050.69 rows=420836 width=2542) (actual time=7519.032..8871.433 rows=516517 loops=1)Output: column1, .., column54Workers Planned: 2Workers Launched: 2Buffers: shared hit=576 read=406221-> Sort (cost=542949.70..543475.75 rows=210418 width=2542) (actual time=7451.958..7649.480 rows=172172 loops=3)Output: column1, .., column54Sort Key: logtable.timestampcol DESCSort Method: quicksort Memory: 58867kBWorker 0: Sort Method: quicksort Memory: 58510kBWorker 1: Sort Method: quicksort Memory: 58788kBBuffers: shared hit=576 read=406221Worker 0: actual time=7438.271..7644.241 rows=172085 loops=1Buffers: shared hit=203 read=135166Worker 1: actual time=7407.574..7609.922 rows=172948 loops=1Buffers: shared hit=202 read=135225-> Parallel Seq Scan on schema.logtable (cost=0.00..524345.70 rows=210418 width=2542) (actual time=2.839..7017.729 rows=172172 loops=3)Output: column1, .., column54Filter: ((logtable.acrhivestatus <= 1) AND ((logtable.entrytype = 4000) OR (logtable.entrytype = 4001) OR (logtable.entrytype = 4002)))Rows Removed by Filter: 4533459Buffers: shared hit=480 read=406221Worker 0: actual time=2.628..7006.420 rows=172085 loops=1Buffers: shared hit=155 read=135166Worker 1: actual time=3.948..6978.154 rows=172948 loops=1Buffers: shared hit=154 read=135225Settings: enable_bitmapscan = 'off', random_page_cost = '1', temp_buffers = '80MB', work_mem = '1GB'Planning Time: 0.621 msExecution Time: 9339.457 msHave you tune shared buffers enough? Each block is of 8k by default.
BTW, please try to reset random_page_cost.Look above.I will try upgrading the minor version next.
I will also try setting up a 13.X version locally and import the data from 12.2 to 13.X and see if it might be faster.Am Do., 6. Mai 2021 um 23:16 Uhr schrieb Imre Samu <pella.samu@xxxxxxxxx>:> Postgres Version : PostgreSQL 12.2,> ... ON ... USING btreeIMHO:The next minor (bugix&security) release is near ( expected ~ May 13th, 2021 ) https://www.postgresql.org/developer/roadmap/so you can update your PostgreSQL to 12.7 ( + full Reindexing recommended ! )
You can find a lot of B-tree index-related fixes.https://www.postgresql.org/docs/12/release-12-3.html Release date: 2020-05-14- Fix possible undercounting of deleted B-tree index pages in VACUUM VERBOSE output- Fix wrong bookkeeping for oldest deleted page in a B-tree index- Ensure INCLUDE'd columns are always removed from B-tree pivot tuples- Avoid repeated marking of dead btree index entries as dead- Fix failure of parallel B-tree index scans when the index condition is unsatisfiablehttps://www.postgresql.org/docs/12/release-12-6.html Release date: 2021-02-11> COLLATE pg_catalog."default"You can test the "C" Collation in some columns (keys ? ) ; in theory, it should be faster :"The drawback of using locales other than C or POSIX in PostgreSQL is its performance impact. It slows character handling and prevents ordinary indexes from being used by LIKE. For this reason use locales only if you actually need them."Best,ImreSemen Yefimenko <semen.yefimenko@xxxxxxxxx> ezt írta (időpont: 2021. máj. 6., Cs, 16:38):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 :The table contains 14.000.000 entries and has about 3.3 GB of data: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.logtableOWNER to user;CREATE INDEX idx_timestampcolON schema.logtable USING btree( timestampcol ASC NULLS LAST )TABLESPACE tablespace ;CREATE INDEX idx_test2ON schema.logtable USING btree( entrytype ASC NULLS LAST)TABLESPACE tablespaceWHERE archivestatus <= 1;CREATE INDEX idx_arcstatusON schema.logtable USING btree( archivestatus ASC NULLS LAST)TABLESPACE tablespace;CREATE INDEX idx_entrytypeON schema.logtable USING btree( entrytype ASC NULLS LAST)TABLESPACE tablespace ;
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 :This improved performance from 45-60 s to 15-35 s. (since we are using ssd's)set random_page_cost = 1;
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)As mentioned before, oracle does this much faster.
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 msIs there much I can analyze, any information you might need to further analyze this?-------------------------------------------------------------------------------------------------------------------------| 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 |---------------------------------------------------------------------------------------------------------------------------Thanks,VijayMumbai, IndiaThanks,VijayMumbai, India
