Re: Bad plan after vacuum analyze

От: Guillaume Smet
Тема: Re: Bad plan after vacuum analyze
Дата: ,
Msg-id: 4282638E.2020307@smet.org
(см: обсуждение, исходный текст)
Ответ на: Re: Bad plan after vacuum analyze  (Tom Lane)
Ответы: Re: Bad plan after vacuum analyze  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Bad plan after vacuum analyze  (Guillaume Smet, )
 Re: Bad plan after vacuum analyze  (Josh Berkus, )
  Re: Bad plan after vacuum analyze  (Tom Lane, )
   Re: Bad plan after vacuum analyze  (Guillaume Smet, )
    Re: Bad plan after vacuum analyze  (Tom Lane, )
     Re: Bad plan after vacuum analyze  (Guillaume Smet, )
      Re: Bad plan after vacuum analyze  (Tom Lane, )
       Re: Bad plan after vacuum analyze  (Guillaume Smet, )
        Re: Bad plan after vacuum analyze  (Markus Bertheau, )
 Re: Bad plan after vacuum analyze  (Mischa Sandberg, )

 > Well, those stats certainly appear to justify the planner's belief that
 > the indexscan needn't run very far: the one value of
 > parent_application_id is 1031 and this is below the smallest value of
 > object_id seen by analyze.

Yes, it seems rather logical but why does it cost so much if it should
be an effective way to find the row?

 > You might have better luck if you increase
 > the statistics target for acs_objects.object_id.

What do you mean exactly?

 > (It'd be interesting
 > to know what fraction of acs_objects actually does have object_id <
1032.)

ccm_perf=# SELECT COUNT(*) FROM acs_objects WHERE object_id<1032;
  count
-------
     15

ccm_perf=# SELECT COUNT(*) FROM acs_objects;
  count
-------
  33510


--
Guillaume


В списке pgsql-performance по дате сообщения:

От: Enrico Weigelt
Дата:
Сообщение: Re: BLOB's bypassing the OS Filesystem for better Image loading speed?
От: Bruce Momjian
Дата:
Сообщение: Re: Intel SRCS16 SATA raid?