Re: [HACKERS] out of memory with large queries

Поиск
Список
Период
Сортировка
От Philip Warner
Тема Re: [HACKERS] out of memory with large queries
Дата
Msg-id 3.0.5.32.19990610123848.00a0fd70@mail.rhyme.com.au
обсуждение исходный текст
Ответ на Re: [HACKERS] out of memory with large queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
At 17:14 9/06/99 -0400, you wrote:
>Massimo Dal Zotto <dz@cs.unitn.it> writes:
>> This means that postgres is currently unable to execute large queries
>> that involve functions on text fields. A pretty bad limitation IMHO.
>
>Yup.  This is one of the major projects that I was proposing for 6.6.
>I do not think the fix will be easy, but we need to do it.
>

In yet another attempt to go over my head, wouldn't it be possible to pass three parameters to the aggregate state
functions,so their signatures become:
 

int (or void) = transfn1 (transtype1, basetype, *transtype1)
int (or void) = transfn2 (transtype2, *transtype2)
int (or void) = finalfn (transtype1, transtype2, *finaltype)

where the int return value *may* give status information, or may just be ignored.

This clearly breaks the ability to use the existing float8pl etc functions, but the cost is reasonably controlled: the
creationof xxxxx3 wrappers (eg. float8pl3) which take three parameters and call the original function, then release the
memory.

A better solution would be to have float8pl accept 2 or 3 parameters, and modify how it returns information based on
theparameter count, but I *presume* that this would break on many platforms/compilers (is this right?), in any case it
seemspretty nasty returning an int OR a float8*, depending on your parameters. Perhaps if the functions were modified
as:

transtype1 = transfn1 (transtype1, basetype [, *transtype1])
transtype2 = transfn2 (transtype2 [, *transtype2])
finaltype = finalfn (transtype1, transtype2 [, *finaltype])

Then they are completely source-compatible with existing functions, but will accept an optional pointer to the storage
fortheir return value (probably a local variable in the caller).
 

If it worked, then each of the aggregates could avoid memory allocation completely, which has to be a performance gain
aswell. Unfortunately, even if this worked on all platforms, I have no idea what it would do to the internals of PG.
 

Am I missing something (again?).


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vadim Mikheev
Дата:
Сообщение: Re: Real Programmers (was: [HACKERS] Priorities for 6.6)
Следующее
От: Philip Warner
Дата:
Сообщение: Re: [HACKERS] Aggregates with context - a question