From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | David L <segedunum(at)actuaria(dot)co(dot)uk> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Using Views as Tables |
Date: | 2017-01-09 14:55:00 |
Message-ID: | CACjxUsOfB6-i8t8zXc8DuSbmoTVhRJbKCjetQ5R486KfyLo1Fg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Sun, Jan 8, 2017 at 10:30 AM, David L <segedunum(at)actuaria(dot)co(dot)uk> wrote:
> [bulk load of data to new table every few months; latest referenced by view]
> This is apparently leading to some confusing results when people are
> querying these views with inconsistent query times. Sometimes queries are
> taking two or three seconds, other times 20 or 30 milliseconds, the latter
> being what we'd expect.
I agree with others that the view has nothing to do with it.
Caching came to mind, but if you have sufficient RAM that the data
from the bulk load remains cached until use, my next two ideas are
statistics or hint bits. Both would be corrected by running VACUUM
FREEZE ANALYZE against the freshly loaded table before modifying
the view to reference it.
If that doesn't help, I suggest trying to create the issue on a
test machine, and seeing what influences the run time. A `vmstat
1` run covering fast and slow cases might help. If necessary,
capture fast and slow plans using EXPLAIN (ANALYZE, BUFFERS,
VERBOSE) both ways, and report as suggested here:
https://wiki.postgresql.org/wiki/SlowQueryQuestions
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2017-01-09 14:56:11 | Re: Fwd: Can I bother you for some more assistance? |
Previous Message | David Steele | 2017-01-09 14:45:45 | Re: Fwd: Can I bother you for some more assistance? |