On Tue, 25 Jun 2019 at 12:23, Justin Pryzby wrote:
> It's possible that the "administrative" queries are using up lots of your
> shared_buffers, which are (also/more) needed by the customer-facing
> queries. I
> would install pg_buffercache to investigate. Or, just pause the admin
> queries
> a
On Wed, 26 Jun 2019 at 15:18, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jun-26, Hugh Ranalli wrote:
> >> From my research in preparing for the upgrade, I understood transparent
> >> huge pages were a good thing, and should be enabled. Is this not
> corr
On Wed, 26 Jun 2019 at 14:52, Peter Geoghegan wrote:
> Can you show us the definition of the table, including its indexes?
> Can you describe the data and distribution of values within the
> columns, particularly where they're indexed?
>
I'm sorry, but I'm not sure what you mean by the "distribu
On Tue, 25 Jun 2019 at 12:23, Justin Pryzby wrote:
> What kernel? Version? OS?
>
Ubuntu 18.04; current kernel is 4.15.0-51-generic4
If Linux, I wonder if transparent hugepages or KSM are enabled ? It seems
> possible that truncating the table is clearing enough RAM to mitigate the
> issue, si
On Tue, 25 Jun 2019 at 11:55, Benjamin Scherrey
wrote:
> Have you done a VACUUM ANALYZE FULL on your database? This needs to be
> done periodically to inform the server of the statistics of how the data
> and relations are distributed across the database. Without this bad
> assumptions by the pla
rows continually, with no cleaning.
If anyone has any suggestions as to what sort of statistics to look at, or
why this would be happening, they would be greatly appreciated.
Thanks in advance,
Hugh
--
Hugh Ranalli
Principal Consultant
White Horse Technology Consulting
e: [email protected]
c: +01-416-994-7957
