Hi
We recently upgraded one of the instances from 9.6.3 to 9.6.12 and seeing
following issue that occurs for few cases.
I have tried running analyze on the table with different values from 1000 -
5000 but it doesn't seem to help the issue. There is some skew in a_id
but the combination index
AminPG Jaffer writes:
> Is there an explanation why it is using incorrect index?
> SQL:
> SELECT count(*) FROM tc WHERE ((tc.a_id = $1)) AND ((tc.m_id = $2)) AND
> ((tc.ag_id is not null)) AND ((tc.id in ($3))) AND ((tc.pt in ($4, $5, $6)))
What data types are these columns? For that matter, co
Here is the table structure.
Column |Type |
Modifiers
---+-+---
id| numeric(38,0) | not null
tname
AminPG Jaffer writes:
> Here is the table structure.
Hpmh. I thought it was just barely possible that you had a datatype
mismatch between the columns and the parameters, but nope, the columns
are "numeric" just like the parameters.
I'm pretty baffled. I tried to duplicate the problem with some
On Tue, Jun 18, 2019 at 2:08 PM Tom Lane wrote:
> Are you perhaps running with non-default values for any planner cost
> parameters? Or it's not a stock build of Postgres?
>
> If you could find a way to adjust the attached example so that it
> produces the same misbehavior you see with live data,
Hi,
On 2019-06-18 06:11:54 -0700, AminPG Jaffer wrote:
> We recently upgraded one of the instances from 9.6.3 to 9.6.12 and seeing
> following issue that occurs for few cases.
>
> We recently upgraded one of the instances from 9.6.3 to 9.6.12 and seeing
> following issue that occurs for few cases
Andres Freund writes:
> Are those indexes used for other queries? Any chance they've been
> recently created?
> SELECT indexrelid::regclass, xmin, indcheckxmin, indisvalid, indisready,
> indislive, txid_current(), txid_current_snapshot()
> FROM pg_index WHERE indrelid = 'tc'::regclass;
> might t
