On Sat, Feb 29, 2020 at 11:22 AM Jeff Janes wrote:
> On Thu, Feb 27, 2020 at 11:33 AM Ben Snaidero
> wrote:
>
>
>> I have the following query that was on average running in ~2ms suddenly
>> jump up to on average ~25ms.
>>
>
> What are you averaging over?
On Fri, Feb 28, 2020 at 2:00 PM legrand legrand
wrote:
> Hello,
> I'm not able to use your perfs diagrams,
> but it seems to me that not using 3rd column of that index (int_otherid2)
> generates an IO problem.
>
> Could you give us the result of
>
> explain (analyze,buffers) SELECT
>
> tabledata.
On Fri, Feb 28, 2020 at 11:41 AM Michael Lewis wrote:
> If no updates or deletes are happening on the table, it would be best
> practice to set up a scheduled manual vacuum analyze to ensure statistics
> and the visibility map is updated. Other than creating the index on the
> first two columns o
On Thu, Feb 27, 2020 at 11:54 AM Michael Lewis wrote:
> How big is ix_tabledata_intid_timestampdate_intotherid3_intotherid2 on
> disk? If you create another index with same fields, how much space does it
> take? Real question- are you vacuuming aggressively enough for your
> workload? Your index
o 50GB on
this server (and 10GB on another server) but in my opinion this is just
masking the issue. Was wondering if anyone in the community has seen
contention with this lock before or has other any insights as to why we
would suddenly run into this issue?
Ben Snaidero
*Geotab*
Senior Database
