Search Postgresql Archives

Re: Workaround for custom aggregate which would need "internal"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Lane wrote:
"Florian G. Pflug" <fgp@xxxxxxxx> writes:

Using perl, and a perl-hash was even slower, so I wrote my to c-functions
(actualy c++), which use a STL hash_set to filter out duplicates.

This makes me fairly nervous, because what's going to ensure that the
memory used by the hash_set is reclaimed?  Particularly if the query
errors out partway through?

hash_set can be told to use a user-defined allocator class, which in turn
can use palloc/pfree, with an appropriate memory context. I'm not
really sure what the "appropriate context" is, as using CurrentMemoryContext
leads to strange crashes. For now, i'm using the standard c++ allocator,
because I figured it should make debugging easier.

Still, the question remains how I can sanely use a c++ object as "state" of
a aggregate...

greetings, Florian Pflug




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux