We had a problem in the 8.X series with COPY IN - it did not respect any
configured maximums and just kept allocating memory until it could fit the
entire COPY contents down to the \. into RAM. Could there be a similar
issue with COPY OUT?
-
Dan
On Wed, Jun 11, 2014 at 6:02 PM, Timothy Garn
>> rhaas=# explain select a from generate_series(1,100) a union select a
>> from generate_series(1,100) a;
>> QUERY PLAN
>> --
>> HashAggregate (cost=45.00..65.00 rows=2000 widt
Hi,
I have a query that's pulling data for another system using COPY (query) to
STDOUT CSV on a 9.2.4 db (we're in the process of upgrading to 9.3). The
final csv file is large (~75GB, 86 million rows). The query is also large,
consisting of one table (86 million rows) left joined to a total of
On 06/13/2014 02:19 AM, Tim Kane wrote:
I ask because I’ve just read your statement above about 3.2 being
pants-on-head, and having had more luck with 3.8 and above – despite
most installations being on much older (2.6.19) kernels (as per the
thread).
Well, the issue is that the 3.2 kernel wa
>
> From: Shaun Thomas
> Date: Tuesday, 10 June 2014 22:07
> So here's the thing. The Linux page reclamation code is *extremely
> broken* in everything before 3.11. Take a look at this, then realize
> that this is *only one patch* from several that target the memory
> manager weightings:
>
>
