Re: unanalyze a foreign table

From: Justin <zzzzz(dot)graf(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: unanalyze a foreign table
Date: 2019-12-23 22:12:20
Message-ID: CALL-XeP0qf=_GCKW7uMakK=ARS_voGGV3y8iJkLnaZjkwfb-wA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I do not know of way to undo an analyze once its committed. I do not know
the danger in deleting an entry in pg_statistic

What you can do in the future is make copy of the Statics for this table,
analyze, if it negatively affect results put the copy back.

Another option is to do

begin ;
ANALYZE my_problem_table ;
explain select my_problem_query;
rollback ;

Foreign tables are not be default analyzed so the statistics should have
been empty or no entry, unless it was previously analyzed.

https://www.postgresql.org/docs/current/sql-analyze.html

On Sun, Dec 22, 2019 at 2:22 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> I did a manual ANALYZE of a foreign table, to see if it would make a
> troublesome query better. It did, but it also made some other queries that
> were previously fine to become far worse. Is there a way to undo the
> analyze? I can muck around in the catalogs like below, but seems really
> grotty.
>
> delete from pg_statistic where starelid=418911;
>
> The other option seems to be doing a `drop foreign table ... cascade`, but
> then recreating all the cascaded drops is quite annoying and error prone.
>
> I currently solved it by re-cloning my performance testing server from
> upstream, but that also is not very convenient. Is directly manipulating
> the catalogs really the best way?
>
> Cheers,
>
> Jeff
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2019-12-23 23:43:44 Re: pgpool High Availability Issue
Previous Message Alban Hertroys 2019-12-23 16:46:28 Re: SQL operator '*='