Hi,
On 2019-07-18 16:01:46 -0400, Hugh Ranalli wrote:
> I've been going by a couple of articles I found about interpreting
> pg_buffercache (
> https://www.keithf4.com/a-large-database-does-not-mean-large-shared_buffers),
> and so far shared buffers look okay. Our database is 486 GB, with shared
>
On 18/07/2019 23:51, mayank rupareliya wrote:
[...]
Thanks Andreas, David, Gavin
/Any particular reason for using varchar instead of text, for field?/ No
use UUID for the user_id.Agreed
/[...]/
/Use of text is preferred, but I can't see it making any significant
difference to performance --
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 Thu, Jul 18, 2019 at 05:21:49PM +0530, mayank rupareliya wrote:
*Please recheck with track_io_timing = on in configuration. explain
(analyze,buffers) with this option will report how many time we spend
during i/o*
*> Buffers: shared hit=2 read=31492*
*31492 blocks / 65 sec ~ 480 IOPS, not
*Please recheck with track_io_timing = on in configuration. explain
(analyze,buffers) with this option will report how many time we spend
during i/o*
*> Buffers: shared hit=2 read=31492*
*31492 blocks / 65 sec ~ 480 IOPS, not bad if you are using HDD*
*Your query reads table data from disks (w
