Robert Haas writes:
> Nice. What was the overall effect on memory consumption?
Before:
cspell: 31352608 total in 3814 blocks; 37432 free (6 chunks); 31315176 used
After:
cspell: 16214816 total in 1951 blocks; 13744 free (12 chunks); 16201072 used
This is on a 32-bit machine that uses MAXALIGN
On Wed, Oct 6, 2010 at 7:36 PM, Tom Lane wrote:
> Teodor Sigaev writes:
>>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>>> on 64bit from 55MB to cca 27MB.
>
>> Good results. But, I think, there are more places in ispell to use
>> hold_memory():
>> - affixes and affix tree
>> - regis
Teodor Sigaev writes:
>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>> on 64bit from 55MB to cca 27MB.
> Good results. But, I think, there are more places in ispell to use
> hold_memory():
> - affixes and affix tree
> - regis (REGex for ISpell, regis.c)
I fixed the affix stuff as mu
Pavel Stehule writes:
> this simple patch reduce a persistent allocated memory for tsearch
> ispell dictionaries.
> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
> on 64bit from 55MB to cca 27MB.
Applied with revisions --- I got rid of the risky static state as per
discussion, and exten
Robert Haas writes:
> On Wed, Oct 6, 2010 at 1:40 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ...but I don't really see why that has to be done as part of this patch.
>>
>> Because patches that reduce maintainability seldom get cleaned up after.
> I don't think you've made a convincing argu
On Wed, Oct 6, 2010 at 1:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think it would be cleaner to get rid of checkTmpCtx() and instead
>> have dispell_init() set up and tear down the temporary context,
>
> What I was thinking of doing was getting rid of the static variable
> altogether: we
Robert Haas writes:
> I think it would be cleaner to get rid of checkTmpCtx() and instead
> have dispell_init() set up and tear down the temporary context,
What I was thinking of doing was getting rid of the static variable
altogether: we should do what you say above, but in the form of a
state s
On Mon, Oct 4, 2010 at 2:05 AM, Pavel Stehule wrote:
> 2010/10/4 Robert Haas :
>> On Oct 3, 2010, at 7:02 PM, Tom Lane wrote:
>>> It's not at all apparent that the code is even
>>> safe as-is, because it's depending on the unstated assumption that that
>>> static variable will get reset once per
Hello
2010/10/4 Robert Haas :
> On Oct 3, 2010, at 7:02 PM, Tom Lane wrote:
>> It's not at all apparent that the code is even
>> safe as-is, because it's depending on the unstated assumption that that
>> static variable will get reset once per dictionary. The documentation
>> is horrible: it doe
On Oct 3, 2010, at 7:02 PM, Tom Lane wrote:
> It's not at all apparent that the code is even
> safe as-is, because it's depending on the unstated assumption that that
> static variable will get reset once per dictionary. The documentation
> is horrible: it doesn't really explain what the patch is
Robert Haas writes:
> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
>> In the particular case here, the dictionary structures could probably
>> safely use such a context type, but I'm not sure it's worth bothering
>> if the long-term plan is to implement a precompiler. There would be
>> no nee
On Fri, Oct 1, 2010 at 2:34 PM, Pavel Stehule wrote:
> Hello
>
> 2010/10/1 Robert Haas :
>> On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
>>> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
In the particular case here, the dictionary structures could probably
safely use such a c
Hello
2010/10/1 Robert Haas :
> On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
>>> In the particular case here, the dictionary structures could probably
>>> safely use such a context type, but I'm not sure it's worth bothering
>>> if the l
On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
>> In the particular case here, the dictionary structures could probably
>> safely use such a context type, but I'm not sure it's worth bothering
>> if the long-term plan is to implement a preco
On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
> In the particular case here, the dictionary structures could probably
> safely use such a context type, but I'm not sure it's worth bothering
> if the long-term plan is to implement a precompiler. There would be
> no need for this after the precom
Heikki Linnakangas writes:
> A more general solution would be to have a new MemoryContext
> implementation that does the same your patch does. Ie. instead of
> tracking each allocation, just allocate a big chunk, and have palloc()
> return the next n free bytes from it, like a stack. pfree() wo
A more general solution would be to have a new MemoryContext
implementation that does the same your patch does. Ie. instead of
tracking each allocation, just allocate a big chunk, and have palloc()
return the next n free bytes from it, like a stack. pfree() would
obviously not work, but wholesale
2010/9/7 Heikki Linnakangas :
> On 07/09/10 19:27, Teodor Sigaev wrote:
>>>
>>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>>> on 64bit from 55MB to cca 27MB.
>>
>> Good results. But, I think, there are more places in ispell to use
>> hold_memory():
>> - affixes and affix tree
>> - regi
2010/9/7 Teodor Sigaev :
>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>> on 64bit from 55MB to cca 27MB.
>
> Good results. But, I think, there are more places in ispell to use
> hold_memory():
> - affixes and affix tree
> - regis (REGex for ISpell, regis.c)
yes, but minimally for Czec
On 07/09/10 19:27, Teodor Sigaev wrote:
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Good results. But, I think, there are more places in ispell to use
hold_memory():
- affixes and affix tree
- regis (REGex for ISpell, regis.c)
A more general solution
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Good results. But, I think, there are more places in ispell to use
hold_memory():
- affixes and affix tree
- regis (REGex for ISpell, regis.c)
--
Teodor Sigaev E-mail: teo.
Hello
this simple patch reduce a persistent allocated memory for tsearch
ispell dictionaries.
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Regards
Pavel Stehule
tsearch_group_alloc.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list
22 matches
Mail list logo