I made a brute force check and indeed, for one of the parameters the query was
switching to sequential scans (or bitmaps scans with condition on survey_pk=16
only if sequential scans were off). After closer look at the plan cardinalities
I thought it would be worthy to increase histogram size an
Krzysztof Nienartowicz writes:
> Logs of the system running queries are not utterly clear, so chasing the
> parameters for the explosive query is not that simple (shared logs between
> multiple threads), but from what I see there is no difference between them
> and the plan looks like (without rem
Hello,
Thank you for the clarifications. The plan as run from the psql looks ok,
also did not notice any specific locks for this particular query.
Logs of the system running queries are not utterly clear, so chasing the
parameters for the explosive query is not that simple (shared logs between
mul
Krzysztof Nienartowicz writes:
> surveys-> SELECT t1.SURVEY_PK, t1.SOURCE_PK, t1.TSTYPE, t1.VALS
> surveys-> FROM sources t0 ,TS t1 where
> surveys-> (t0.SURVEYID = 16 AND t0.SRCID >= 203510110032281 AND
> t0.SRCID <= 203520107001677 and t0.SURVEYID = t1.SURVEY_PK AND t0.SRCID =
> t1.SOURCE_
Hello,
Sorry for the re-post - not sure list is the relevant one, I included
slightly changed query in the previous message, sent to bugs list.
I have an ORM-generated queries where parent table keys are used to
fetch the records from the child table (with relevant FK indicies),
where child tabl
Hello,
I have an ORM-generated queries where parent table keys are used to
fetch the records from the child table (with relevant FK indicies),
where child table is partitioned. My understanding is that Postgres is
unable to properly use constraint exclusion to query only a relevant
table? Half of t
