On Thu, Nov 07, 2019 at 01:15:30PM +1300, David Rowley wrote:
> On Thu, 7 Nov 2019 at 11:59, Justin Pryzby wrote:
> >
> > On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> > > Postgres version 9.5.19
> > > Each of the tables has between 3-4 indexes, and all the indexes include
> >
On Thu, 7 Nov 2019 at 11:59, Justin Pryzby wrote:
>
> On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> > Postgres version 9.5.19
> > Each of the tables has between 3-4 indexes, and all the indexes include tid
> > as first parameter.
> But note that index definition will be prohi
Is default_statistics_target set above default 100? I would assume that would
reflect in the size of pg_statistic, but wanted to ask since increasing that
from 100 to 1000 was the only time I have seen planning time explode. Are other
queries slow to plan?
Looks like you’ve found it! Someone ha
On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> Postgres version 9.5.19
> Each of the tables has between 3-4 indexes, and all the indexes include tid
> as first parameter.
On Mon, Nov 04, 2019 at 12:00:59AM -0500, Tom Lane wrote:
> If this *is* the cause, v11 and up have a perfor
Is default_statistics_target set above default 100? I would assume that
would reflect in the size of pg_statistic, but wanted to ask since
increasing that from 100 to 1000 was the only time I have seen planning
time explode. Are other queries slow to plan?
vid Wheeler
Cc: Tom Lane , "pgsql-performance@lists.postgresql.org"
, Cameron Redpath
Subject: Re: Slow planning, fast execution for particular 3-table query
po 4. 11. 2019 v 6:17 odesílatel David Wheeler
mailto:dwhee...@dgitsystems.com>> napsal:
>To see this issue, you have
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
13 matches
Mail list logo
