Chuck McDevitt píše v út 19. 05. 2009 v 09:33 -0700:
>
> Solaris default malloc always uses sbrk(), and never ever tried to reduce the
> sbrk point.
>
> If you want a malloc that uses mmap, there is an non-default malloc that does
> that (libumem or something?)
>
There are severals memory a
On Tue, May 19, 2009 at 5:59 PM, Steve Prentice wrote:
> I followed the past discussions regarding the syntax for named parameters
> and I am currently using Pavel Stehule's patch for named and mixed notation
> on top of the 8.4 beta.
>
> It seems the way plpgsql substitutes $1, $2, etc for the pa
I followed the past discussions regarding the syntax for named
parameters and I am currently using Pavel Stehule's patch for named
and mixed notation on top of the 8.4 beta.
It seems the way plpgsql substitutes $1, $2, etc for the parameters is
going to reduce the usefulness of this feature
Adriano Lange escreveu:
I implemented the 2PO algorithm last month but I didn't have much time
to do an extensive test and to comment all code. The code was posted in
this list in a previous thread. In that occasion, I was interested in a
kind of cache structure to avoid the constructing a comp
Robert Haas escreveu:
On Wed, May 13, 2009 at 4:14 PM, Tobias Zahn wrote:
Hello,
thank you for posting the paper, it was quite interesting to read. I
think it would be a good idea to give the two-phase optimization a try.
As far as I know and understand the current (geqo) optimizer source,
many
Well I'm just saying if you realloc a x kilobyte block into a 2x block
and the allocator can't expand it and has to copy then it seems
inevitable.
--
Greg
On 19 May 2009, at 14:11, Simon Riggs wrote:
On Tue, 2009-05-19 at 13:52 +0100, Greg Stark wrote:
So at least transiently we use 3
On Tue, 2009-05-19 at 13:52 +0100, Greg Stark wrote:
> So at least transiently we use 3x the size of the actual array.
I was conjecturing, prior to investigation. Are you saying you know
this/have seen this already?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services a
On Tue, 2009-05-19 at 09:33 -0700, Chuck McDevitt wrote:
> > Is it possible that Solaris's default malloc isn't appropriate for
> > repeated use in complex queries that use multiple sorts?
> > http://developers.sun.com/solaris/articles/multiproc/multiproc.html
> > and recent OpenSolaris bug repor
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Simon Riggs
> Sent: Tuesday, May 19, 2009 4:32 AM
> To: pgsql-hackers
> Subject: [HACKERS] Multiple sorts in a query
>
>
> Just wanted to check some thoughts about
On May 19, 2009, at 10:52 AM, Robert Haas wrote:
How 'bout we flip that around? :-)
+1
(BTW, I know there's pg_dump, but being able to get SQL out of psql
is just a lot more convenient)
--
Decibel!, aka Jim C. Nasby, Database Architect deci...@decibel.org
Give your computer some brain ca
On Tue, May 19, 2009 at 7:44 AM, Martijn van Oosterhout
wrote:
> On Tue, May 19, 2009 at 12:32:13PM +0100, Simon Riggs wrote:
>> If we allocate large chunks of memory we use malloc(). So complex
>> queries can have multiple mallocs, followed by multiple reallocs. That
>> in itself seems likely to
On May 19, 2009, at 11:31 AM, decibel wrote:
On May 19, 2009, at 10:27 AM, Tom Lane wrote:
Robert Haas writes:
On May 19, 2009, at 10:02 AM, Greg Stark >
wrote:
One advantage of the current arrangement is that the constraints
and
triggers are almost (though not quite) in the same form as
On Tue, May 19, 2009 at 12:32 PM, Simon Riggs wrote:
>
> If we have a query that uses multiple sorts, we may have a top-level
> sort, with child nodes that contain sorts also. In some cases we may
> find with sub-nodes that have both inner and outer sub-trees that
> contain sorts also.
Well a top
decibel writes:
> On May 19, 2009, at 10:27 AM, Tom Lane wrote:
>> +1 --- I *very* often find myself copying-and-pasting from \d output,
>> and the proposed tabular format would be a huge step backwards for
>> that. Personally I kinda wish that the column display were closer
>> to what CREATE TAB
On May 19, 2009, at 10:27 AM, Tom Lane wrote:
Robert Haas writes:
On May 19, 2009, at 10:02 AM, Greg Stark
wrote:
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the
command to create them. It would be sad to lo
Robert Haas writes:
> On May 19, 2009, at 10:02 AM, Greg Stark
> wrote:
>> One advantage of the current arrangement is that the constraints and
>> triggers are almost (though not quite) in the same form as the
>> command to create them. It would be sad to lose that competely.
> Agreed.
+1
On May 19, 2009, at 10:02 AM, Greg Stark
wrote:
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the
command to create them. It would be sad to lose that competely.
Agreed. What I most often want to do is eit
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the command
to create them. It would be sad to lose that competely.
Is there any room for a compromise? Something that just reduces the
clutter incrementally inste
On May 19, 2009, at 9:41 AM, decibel wrote:
On May 18, 2009, at 10:25 PM, Tom Lane wrote:
decibel writes:
The gripe I have with \d is that the "footnotes" are very hard to
scan through once you have more than a few things on a table. What
I'd like to see is a version that provides the same i
On May 18, 2009, at 10:25 PM, Tom Lane wrote:
decibel writes:
The gripe I have with \d is that the "footnotes" are very hard to
scan through once you have more than a few things on a table. What
I'd like to see is a version that provides the same information, but
in a tabular output.
Hmm, I'm
On Tue, 2009-05-19 at 09:17 -0400, Merlin Moncure wrote:
> On Tue, May 19, 2009 at 7:44 AM, Martijn van Oosterhout
> >
> > The threshold is dynamic apparently, but starts at 128KB.
>
> I just read an article that suggests assuming that can be dangerous
> (by one of the authors of jemalloc)...an i
On Tue, May 19, 2009 at 12:32:13PM +0100, Simon Riggs wrote:
> If we allocate large chunks of memory we use malloc(). So complex
> queries can have multiple mallocs, followed by multiple reallocs. That
> in itself seems likely to end up with roughly double memory use, since
> realloc won't work pro
Just wanted to check some thoughts about how memory allocation works in
complex queries. Been thinking some more about recent Solaris testing
results that *seemed* to show issues with multiple concurrent queries
that have multiple sorts.
If we have a query that uses multiple sorts, we may have a
23 matches
Mail list logo
