On Apr 9, 2011, at 9:23 PM, Stephen Frost wrote:
> Actually, Tom has a point in that work_mem can be set above 1GB (which
> is where I had it set previously..). I didn't think it'd actually do
> anything given the MaxAlloc limit, but suprisingly, it does (at least,
> under 8.4). I'm currently try
* Greg Stark (gsst...@mit.edu) wrote:
> On Sat, Apr 9, 2011 at 6:20 PM, Tom Lane wrote:
> > BTW, it sounded like your argument had to do with whether it would use
> > HashAgg or not -- that is *not* dependent on the per-palloc limit, and
> > never has been.
>
> His point was he wanted to be allow
On Sun, 2011-04-10 at 03:05 +0100, Greg Stark wrote:
> On Sat, Apr 9, 2011 at 6:20 PM, Tom Lane wrote:
> > BTW, it sounded like your argument had to do with whether it would use
> > HashAgg or not -- that is *not* dependent on the per-palloc limit, and
> > never has been.
> >
>
> His point was he
On Sat, Apr 9, 2011 at 6:20 PM, Tom Lane wrote:
> BTW, it sounded like your argument had to do with whether it would use
> HashAgg or not -- that is *not* dependent on the per-palloc limit, and
> never has been.
>
His point was he wanted to be allowed to set work_mem > 1GB. This is
going to becom
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> If we were actually trying to support such large allocations,
>> what I'd be inclined to do is introduce a separate call along the lines
>> of MemoryContextAllocLarge() that lacks the safety check.
> This sounds like the right ap
Tom, all,
Having run into issues caused by small work_mem, again, I felt the need
to respond to this.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> You would break countless things. It might be okay anyway in a trusted
> environment, ie, one without users trying to crash the system, but there
> are a
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> You seem to be confusing one limitation in one code path with the
> >> overall meaning of maintenance_work_mem.
>
> > Oh, OK, so sorts are limited, but not hash sizes? Are there any other
> > uses? Should this be documented someho
Tom Lane wrote:
> Bruce Momjian writes:
> > Well, I figure it will be hard to allow larger maximums, but can we make
> > the GUC variable maximums be more realistic? Right now it is
> > MAX_KILOBYTES (INT_MAX).
>
> You seem to be confusing one limitation in one code path with the
> overall meani
Bruce Momjian writes:
> Tom Lane wrote:
>> You seem to be confusing one limitation in one code path with the
>> overall meaning of maintenance_work_mem.
> Oh, OK, so sorts are limited, but not hash sizes? Are there any other
> uses? Should this be documented somehow? What is the actual sort
>
Bruce Momjian writes:
> Well, I figure it will be hard to allow larger maximums, but can we make
> the GUC variable maximums be more realistic? Right now it is
> MAX_KILOBYTES (INT_MAX).
You seem to be confusing one limitation in one code path with the
overall meaning of maintenance_work_mem.
--On 20. Februar 2011 15:48:06 +0100 Bernd Helmle
wrote:
Well, I figure it will be hard to allow larger maximums, but can we make
the GUC variable maximums be more realistic? Right now it is
MAX_KILOBYTES (INT_MAX).
This is something i proposed some time ago, too. At least, it will stop
--On 20. Februar 2011 09:32:02 -0500 Bruce Momjian wrote:
Well, I figure it will be hard to allow larger maximums, but can we make
the GUC variable maximums be more realistic? Right now it is
MAX_KILOBYTES (INT_MAX).
This is something i proposed some time ago, too. At least, it will stop u
Devrim G?ND?Z wrote:
> On Wed, 2011-02-16 at 23:24 +0200, Peter Eisentraut wrote:
> >
> > > But before expending time on that, I'd want to see some evidence
> > that
> > > it's actually helpful for production situations. I'm a bit dubious
> > > that you're going to gain much here.
> >
> > If you
On Wed, 2011-02-16 at 23:24 +0200, Peter Eisentraut wrote:
>
> > But before expending time on that, I'd want to see some evidence
> that
> > it's actually helpful for production situations. I'm a bit dubious
> > that you're going to gain much here.
>
> If you want to build an index on a 500GB ta
Frederik Ramm writes:
> The single query where pg9.0 beat pg8.3 by a country mile was a CREATE
> INDEX statement on a BIGINT column to a table with about 500 million
> records - this cost 2679 seconds on normal 8.3, 2443 seconds on
> large-memory 8.3, and aroung 1650 seconds on 9.0, large memor
Tom & Kevin,
thank you for your replies. Kevin, I had already employed all the
tricks you mention, except using temporary tables which would be hard
for me due to the structure of my application (but I could try using
something like pgbouncer or so), but thanks a lot for sharing the ideas.
On mån, 2011-02-14 at 10:11 -0500, Tom Lane wrote:
> But before expending time on that, I'd want to see some evidence that
> it's actually helpful for production situations. I'm a bit dubious
> that you're going to gain much here.
If you want to build an index on a 500GB table and you have 1TB RA
Frederik Ramm wrote:
> I am (ab)using a PostgreSQL database (with PostGIS extension) in
> a large data processing job - each day, I load several GB of data,
> run a lot of analyses on it, and then throw everything away again.
> Loading, running, and dumping the results takes about 18 hours
> eve
Frederik Ramm writes:
> Now I assume that there are reasons that you're doing this. memutils.h
> has the (for me) cryptic comment about MaxAllocSize: "XXX This is
> deliberately chosen to correspond to the limiting size of varlena
> objects under TOAST. See VARATT_MASK_SIZE in postgres.h.", but
Hi,
I am (ab)using a PostgreSQL database (with PostGIS extension) in a
large data processing job - each day, I load several GB of data, run a
lot of analyses on it, and then throw everything away again. Loading,
running, and dumping the results takes about 18 hours every day.
The job inv
20 matches
Mail list logo
