Re: [HACKERS] Its not my fault. Its SEG's FAULT!

Поиск
Список
Период
Сортировка
От Vadim B. Mikheev
Тема Re: [HACKERS] Its not my fault. Its SEG's FAULT!
Дата
Msg-id 352470D4.C32F5BD3@sable.krasnoyarsk.su
обсуждение исходный текст
Ответ на Re: [HACKERS] Its not my fault. Its SEG's FAULT!  ("Maurice Gittens" <mgittens@gits.nl>)
Ответы Re: [HACKERS] Its not my fault. Its SEG's FAULT!  (dg@illustra.com (David Gould))
Список 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 по дате отправления:

Предыдущее
От: Tom Ivar Helbekkmo
Дата:
Сообщение: Re: [HACKERS] Its not my fault. Its SEG's FAULT!
Следующее
От: Brett McCormick
Дата:
Сообщение: inherited sequences and primary keys