From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gavin Flower <gavinflower(at)archidevsys(dot)co(dot)nz>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: In progress INSERT wrecks plans on table |
Date: | 2013-05-07 06:10:26 |
Message-ID: | CA+U5nMJqUHE-t5eBuMZGu-_0rJbfoqrYJ=oi_xvKhrq8_31F2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 7 May 2013 01:23, <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
> I'm thinking that a variant of (2) might be simpler to inplement:
>
> (I think Matt C essentially beat me to this suggestion - he originally
> discovered this issue). It is probably good enough for only *new* plans to
> react to the increased/increasing number of in progress rows. So this
> would require backends doing significant numbers of row changes to either
> directly update pg_statistic or report their in progress numbers to the
> stats collector. The key change here is the partial execution numbers
> would need to be sent. Clearly one would need to avoid doing this too
> often (!) - possibly only when number of changed rows >
> autovacuum_analyze_scale_factor proportion of the relation concerned or
> similar.
Are you loading using COPY? Why not break down the load into chunks?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2013-05-07 06:32:20 | Re: In progress INSERT wrecks plans on table |
Previous Message | Karl O. Pinc | 2013-05-07 05:32:36 | Make targets of doc links used by phpPgAdmin static |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2013-05-07 06:32:20 | Re: In progress INSERT wrecks plans on table |
Previous Message | Igor Neyman | 2013-05-07 02:03:56 | Re: Deterioration in performance when query executed in multi threads |