From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | get_actual_variable_range vs idx_scan/idx_tup_fetch |
Date: | 2014-10-17 21:43:17 |
Message-ID: | 54418D75.2000303@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However, after looking into our queries more closely, it turns
out that it was only being used to look up statistics for the foo.a
column to estimate merge scan viability during planning. But this took
hours for two people to track down.
So what I'd like to have is a way to be able to distinguish between
indexes being used to answer queries, and ones being only used for stats
lookups during planning. Perhaps the easiest way would be adding a new
column or two into pg_stat_all_indexes, which we would increment in
get_actual_variable_range() when fetching data.
Any thoughts?
.marko
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-10-17 21:47:59 | Re: get_actual_variable_range vs idx_scan/idx_tup_fetch |
Previous Message | Tom Lane | 2014-10-17 21:41:09 | Re: json function volatility |