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.uuid_id,tabledata.int_id,tabledata.timestamp_date,tabledata.int_otherid,ta
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
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 lar
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
