supp...@mekong.be wrote:
> EXPLAIN (ANALYZE, BUFFERS), not just EXPLAIN
> "Index Scan using ix_companyarticledb_company on companyarticledb
> (cost=0.57..2.80 rows=1 width=193) (actual time=1011.335..1011.454 rows=1
> loops=1)"
> " Index Cond: (companyid = 77)"
> " Filter: (articleid =
> Indexes:
> "pk_pricedb" PRIMARY KEY, btree (companyid, articleid)
> "EnabledIndex" btree (enabled)
> "ix_companyarticledb_article" btree (articleid)
> "ix_companyarticledb_company" btree (companyid)
>
I'd say drop ix_companyarticledb_company since pk_pricedb can be used
instead
Hello,
Things to Try Before You Post
-> I went through these steps and they did not bring any difference.
Information You Need To Include
Postgres version
"PostgreSQL 10.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian
6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit"
Full Table and Index Schema
The
On Mon, Feb 25, 2019 at 3:54 AM kimaidou wrote:
> Wich strikes me is that if I try to simplify it a lot, removing all data
> but the main table (occtax.observation) primary key cd_nom and aggregate,
> the query plan should be able tu use the cd_nom index for sorting and
> provide better query
I manage to avoid the disk sort after performing a VACUUM ANALYSE;
And with a session work_mem = '250MB'
* SQL http://paste.debian.net/1070207/
* EXPLAIN https://explain.depesz.com/s/nJ2y
It stills spent 16s
It seems this kind of query will need better hardware to scale...
Thanks for your help
