| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Guillaume Cottenceau <gc(at)mnc(dot)ch> |
| Cc: | "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: much slower query in production |
| Date: | 2020-02-26 22:59:56 |
| Message-ID: | CAMkU=1yhN7Hum7wDLa71dC3AeYHxQDNGosN5-yefWrnauR-GBg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Feb 26, 2020 at 11:17 AM Guillaume Cottenceau <gc(at)mnc(dot)ch> wrote:
> Dear all,
>
> I am facing a much, much slower query in production than on my
> development computer using a restored production backup, and I
> don't understand why nor I see what I could do to speedup the
> query on production :/
>
You've already seen a VACUUM fixed it.
This must have been a logical restore (from pg_dump), not a physical
restore (from pg_basebackup for example) correct?
A physical restore should have resulted in a database in the same state of
vacuuming as its source was. A logical restore will not, and since it is
an append-only process it will not trigger autovacuum to run, either.
If you do a logical restore, probably the first should you do afterwards is
a VACUUM ANALYZE.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2020-02-26 23:17:58 | Re: much slower query in production |
| Previous Message | Pavel Stehule | 2020-02-26 20:40:02 | Re: proposal: schema variables |