<<
I had thought you were saying that any one ETL procedure into one database
used 14 concurrent threads. But really, each ETL procedure is
single-threaded, and there can be up to 5 (or theoretically up to 14) of
them running at a time into different databases?
>>
Sorry, just caught this.
> Someone commented they think it might be related to this kernel bug:
>
> https://lkml.org/lkml/2012/10/9/210
>
We have some evidence that that is the case.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql
<< pgbouncer is more for making connections line up single-file when the
line is moving at a very fast clip, say 0.01 second per turn. If I were
trying to make tasks that can each last for hours or days line up and take
turns, I don't think pgbouncer would be the way to go.
>>
The recommendati
On Tue, Feb 26, 2013 at 4:33 PM, Carlo Stonebanks <
stonec.regis...@sympatico.ca> wrote:
> < description apply to just one of the many (how many?) databases, so that
> there are really 14*N concurrent sessions?
>
> >>** **
>
> ** **
>
> All writes are single row. All DB’s have exactly the same
Quick follow up... I've found that the row estimate in:
explain select count(id) from versions where project_id IN (80,115)
AND project_id=115;
QUERY PLAN
Dmitry Karasik writes:
> I need to have a sort of a time machine, where select statements on tables
> could be easily replaced to select statements on tables as they were some
> time in the past,
> including all related table. To do so, I used views (see in the script) that
> UNION
> both curre
On 27/02/2013 9:29 AM, Josh Berkus wrote:
Andre,
Please see the related thread on this list, "High CPU usage / load
average after upgrading to Ubuntu 12.04". You may be experiencing some
of the same issues. General perspective seems to be that kernels 3.0
through 3.4 have serious performance i
Dear all,
I have a problem with seqscan I hope you might help me with.
Attached is the simple script that reproduces a database and results, which I
have tested both on 9.0.4 and 9.3-devel with identical results.
I need to have a sort of a time machine, where select statements on tables
could be