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
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
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,
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
Here is the table structure.
Column |Type |
Modifiers
---+-+---
id| numeric(38,0) | not null
tname
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
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
