Re: [PERFORM] Query planner wants to use seq scan

Yes, the three fields index AND vacuum solve the issue. Regards, Bertrand 2015-10-29 13:27 GMT+01:00 Alex Ignatov : > > > On 27.10.2015 23:56, Bertrand Paquet wrote: > > So, > > Tonight, the index on the three field is used, may be my yesterday vacuum > updated stats. > > Thx you for your help.

Re: [PERFORM] Query planner wants to use seq scan

On 27.10.2015 23:56, Bertrand Paquet wrote: So, Tonight, the index on the three field is used, may be my yesterday vacuum updated stats. Thx you for your help. Regards, Bertrand 2015-10-27 18:33 GMT+01:00 Bertrand Paquet mailto:bertrand.paq...@doctolib.fr>>: Hi tom, I did

Re: [PERFORM] Query planner wants to use seq scan

On 10/27/15 3:56 PM, Bertrand Paquet wrote: Tonight, the index on the three field is used, may be my yesterday vacuum updated stats. BTW, you can run just ANALYZE, which is *far* faster than a VACUUM on a large table. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in

Re: [PERFORM] Query planner wants to use seq scan

So, Tonight, the index on the three field is used, may be my yesterday vacuum updated stats. Thx you for your help. Regards, Bertrand 2015-10-27 18:33 GMT+01:00 Bertrand Paquet : > Hi tom, > > I did the test yesterday with an index on the three fields, and with a > partial index on organiz

Re: [PERFORM] Query planner wants to use seq scan

Hi tom, I did the test yesterday with an index on the three fields, and with a partial index on organization and status and where is null condition on handled. I saw no modification on query plan. May be I forgot to analyze vacuum after. I will retry tonight. I use a btree index. Is it the good s

Re: [PERFORM] Query planner wants to use seq scan

Hi tom, I did the test yesterday with an index on the three fields, and with a partial index on organization and status and where is null condition on handled. Le mardi 27 octobre 2015, Tom Lane a écrit : > Bertrand Paquet writes: > > We have a slow query. After analyzing, the planner decision

Re: [PERFORM] Query planner wants to use seq scan

show random_page_cost ; random_page_cost -- 4 (1 row) 2015-10-27 12:30 GMT+01:00 Alex Ignatov : > > > On 27.10.2015 14:19, Bertrand Paquet wrote: > > relname | n_live_tup | n_dead_tup | last_vacuum > |last_autovacuum|

Re: [PERFORM] Query planner wants to use seq scan

Bertrand Paquet writes: > We have a slow query. After analyzing, the planner decision seems to be > discutable : the query is faster when disabling seqscan. See below the two > query plan, and an extract from pg_stats. > Any idea about what to change to help the planner ? Neither one of those pl

Re: [PERFORM] Query planner wants to use seq scan

On 27.10.2015 14:19, Bertrand Paquet wrote: relname | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum| last_analyze | last_autoanalyze +++---+---

Re: [PERFORM] Query planner wants to use seq scan

relname | n_live_tup | n_dead_tup | last_vacuum |last_autovacuum| last_analyze | last_autoanalyze +++---+---+---

Re: [PERFORM] Query planner wants to use seq scan

On 27.10.2015 14:10, Bertrand Paquet wrote: Yes, I have run VACUUM ANALYZE, no effect. Bertrand 2015-10-27 12:08 GMT+01:00 Alex Ignatov >: On 27.10.2015 12:35, Bertrand Paquet wrote: Hi all, We have a slow query. After analyzing, the plan

Re: [PERFORM] Query planner wants to use seq scan

Yes, I have run VACUUM ANALYZE, no effect. Bertrand 2015-10-27 12:08 GMT+01:00 Alex Ignatov : > On 27.10.2015 12:35, Bertrand Paquet wrote: > >> Hi all, >> >> We have a slow query. After analyzing, the planner decision seems to be >> discutable : the query is faster when disabling seqscan. See b

Re: [PERFORM] Query planner wants to use seq scan

On 27.10.2015 12:35, Bertrand Paquet wrote: Hi all, We have a slow query. After analyzing, the planner decision seems to be discutable : the query is faster when disabling seqscan. See below the two query plan, and an extract from pg_stats. Any idea about what to change to help the planner ?

[PERFORM] Query planner wants to use seq scan

Hi all, We have a slow query. After analyzing, the planner decision seems to be discutable : the query is faster when disabling seqscan. See below the two query plan, and an extract from pg_stats. Any idea about what to change to help the planner ? An information which can be useful : the number