Re: About Custom Aggregates, C Extensions and Memory

2025-08-18 Thread Marthin Laubscher
Tom Lane t...@sss.pgh.pa.us wrote: > Well, yeah, that's the problem. You can certainly maintain your own > persistent data structure somewhere, but then it's entirely on your head to > manage it and avoid memory leakage/bloating as you process more and more > data. T

Re: About Custom Aggregates, C Extensions and Memory

2025-08-18 Thread Tom Lane
Marthin Laubscher writes: > Essentially the aggregate functions would still be front and centre as > defined for the user defined type, and though the user defined type itself > would be largely unaware of it, all the individual functions that manipulate > values of the UDT would go through the

Re: About Custom Aggregates, C Extensions and Memory

2025-08-17 Thread Marthin Laubscher
Tom Lane t...@sss.pgh.pa.us wrote: > Hm. We do not have in-memory tables, although in some cases a temporary table > is close enough. Yay, I didn't somehow overlook them. > But there is one other pre-existing mechanism that might help you: "expanded > objects". The

Re: About Custom Aggregates, C Extensions and Memory

2025-08-16 Thread Tom Lane
Marthin Laubscher writes: > I was fixing on (ab)using user-defined aggregates for a concept that would, > on second thought, be better described as a key-only table persisted and > manipulated as a single opaque value that is only ever expanded to a > table/set/collection in memory. Initial foc

Re: About Custom Aggregates, C Extensions and Memory

2025-08-16 Thread Marthin Laubscher
Tom Lane < t...@sss.pgh.pa.us> writes: > Yeah. What you want is to declare the aggregate as having transtype > "internal" (which basically means that ExecAgg will store a pointer > for you) and make that pointer point to a data structure kept in the > "aggcontext", which will have a suitable lifes

Re: About Custom Aggregates, C Extensions and Memory

2025-08-15 Thread Tom Lane
Marthin Laubscher writes: > A custom aggregate seems the best vehicle for what I seek to implement. Given > the processing involved, it’s probably best written in C. > That makes the aggregate and opaque value encoded and compressed to an > internal format that allows direct equality testing and

About Custom Aggregates, C Extensions and Memory

2025-08-15 Thread Marthin Laubscher
Hi, I’ll skip over context (until someone asks or I can showcase the results) and cut to the chase: A custom aggregate seems the best vehicle for what I seek to implement. Given the processing involved, it’s probably best written in C. That makes the aggregate and opaque value encoded