Re: [HACKERS] Its not my fault. Its SEG's FAULT! - Mailing list pgsql-hackers

From Vadim B. Mikheev
Subject Re: [HACKERS] Its not my fault. Its SEG's FAULT!
Date
Msg-id 352470D4.C32F5BD3@sable.krasnoyarsk.su
Whole thread Raw
In response to Re: [HACKERS] Its not my fault. Its SEG's FAULT!  ("Maurice Gittens" <mgittens@gits.nl>)
Responses Re: [HACKERS] Its not my fault. Its SEG's FAULT!
List pgsql-hackers
I agreed with Maurice.
Using GC instead of MemoryDuration everywhere isn't good idea for
database server.

But we could implement additional GC-like allocation mode and use it
where is appropriate!

One example - using float8 (etc) in WHERE. We could switch to GC-allocation
in the beginnig of ExecQual () and destroy all allocations made in GC-mode
before return().

Another example - psort.c! With -S 8192 I see that server uses ~ 30M
of memory - due to malloc/palloc overhead in palloc() for each tuple.
No one of these allocations will be freed untill psort_end() <-
good place for GC-destroyer.

Comments ?

Vadim

pgsql-hackers by date:

Previous
From: Tom Ivar Helbekkmo
Date:
Subject: Re: [HACKERS] Its not my fault. Its SEG's FAULT!
Next
From: Brett McCormick
Date:
Subject: inherited sequences and primary keys