> Thanks for the suggestion. Yes I could change the sql and when using only
> one filter for int_otherid2 it does use all 3 columns as the index key.
explain (analyze,buffers) SELECT
uuid_id,int_id,timestamp_date,int_otherid,float_value,int_otherid2,int_otherid3,int_rowver
FROM tabledata WHERE
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? The plan you show us is slow enough
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
>
>
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? The plan you show us is slow enough that if
you were averaging over the last 1000 executions, that one
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
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
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 only, I'm out of ideas. Hopefully someone running
Postgres at
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
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 name seems to indicate that intotherid3 would be the
third key,
Running into a strange issue that just popped up on a few servers in my
environment and was wondering if the community had any insight into as to
what could be causing the issue.
First, a bit of background. I am running Postgres 10.11 on Windows (but
have seen similar issue on a server running
10 matches
Mail list logo
