On Thu, Aug 22, 2019 at 07:54:57PM +0200, Marco Colli wrote:
> I have completely solved (from 17s to 1s) by running this command:
> vacuum analyze subscriptions;
Thanks for following though.
On Thu, Aug 22, 2019 at 08:19:10AM -0500, Justin Pryzby wrote:
> You can see it used the same index in bot
I have completely solved (from 17s to 1s) by running this command:
vacuum analyze subscriptions;
Now I run the autovacuum more frequently using these settings in
postgresql.conf:
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.01
Thanks to everyone - and in particular to
>
> You can SELECT reltuples FROM pg_class WHERE oid='subscriptions'::oid, but
> its
> accuracy depends on frequency of vacuum (and if a large delete/insert
> happened
> since the most recent vacuum/analyze).
>
This only seems helpful to find approx. count for the entire table, without
considering
On Thu, Aug 22, 2019 at 02:44:15PM +0200, Marco Colli wrote:
> SELECT COUNT(*) FROM "subscriptions" WHERE "subscriptions"."project_id" = 123;
> SELECT COUNT(*) FROM "subscriptions" WHERE "subscriptions"."project_id" = 123
> AND "subscriptions"."trashed_at" IS NULL;
>-> Bitmap Heap Scan on su
Dear ,
Create the below indexes and try it !!!
create index ind_ subscriptions_ project_id on
"subscriptions"("project_id")
Where "project_id"= 1
create index ind_ subscriptions_ trashed_at on "subscriptions"("
trashed_at ")
Where "trashed_at" is null
On Thu, Aug 22, 2019 at 6:36 PM Marc
Hi Marco,
Since you said approximates would be good enough, there are two ways to
do that. Query pg_class.reltuples or pg_stat_user_tables.n_live_tup.
Personally, I prefer the pg_stat_user tables since it is more current
than pg_class table, unless you run ANALYZE on your target table before
