po 4. 11. 2019 v 6:17 odesílatel David Wheeler
napsal:
> >To see this issue, you have to have recently
> >inserted or deleted a bunch of extremal values of the indexed join-key
> >column. And the problem only persists until those values become known
> >committed-good, or known de
>To see this issue, you have to have recently
>inserted or deleted a bunch of extremal values of the indexed join-key
>column. And the problem only persists until those values become known
>committed-good, or known dead-to-everybody. (Maybe you've got a
>long-running transacti
David Wheeler writes:
> We’re having trouble working out why the planning time for this
> particular query is slow (~2.5s vs 0.9ms execution time). As you can see
> below, there are only 3 tables involved so it’s hard to imagine what
> decisions the planner has to make that take so long.
I wonder
David Wheeler wrote:
> I'm not sure what "unusually large" is, but they're all < 1mb which is a
> little larger
> than some of our other comparable databases (mostly <300kb) but seems
> reasonable to me.
I forgot the condition "AND n.nspname = 'pg_catalog'"...
But if all your tables are small,
I'm not sure what "unusually large" is, but they're all < 1mb which is a little
larger than some of our other comparable databases (mostly <300kb) but seems
reasonable to me.
Regards,
David
On 4/11/19, 3:37 pm, "Laurenz Albe" wrote:
On Mon, 2019-11-04 at 03:04 +, David Wheeler wr
On Mon, 2019-11-04 at 03:04 +, David Wheeler wrote:
> We’re having trouble working out why the planning time for this particular
> query is slow
> (~2.5s vs 0.9ms execution time). As you can see below, there are only 3
> tables involved
> so it’s hard to imagine what decisions the planner has
We’re having trouble working out why the planning time for this particular
query is slow (~2.5s vs 0.9ms execution time). As you can see below, there are
only 3 tables involved so it’s hard to imagine what decisions the planner has
to make that take so long. After 5 runs the prepared-statement c
