On 2019-Jan-03, Andres Freund wrote: > Hi, > > On 2019-01-03 15:13:42 -0300, Alvaro Herrera wrote:
> > Hmm, without looking at the patches, I agree that the tuples should be > > given as slots to the logical decoding interface. I wonder if we need a > > further function in the TTS interface to help decoding, or is the > > "getattr" stuff sufficient. > > What precisely do you mean with "getattr stuff"? I'd assume that you'd > normally do a slot_getallattrs() and then access tts_values/nulls > directly. Ah, yeah, you deform the tuple first and then access the arrays directly, right. I was just agreeing with your point that forming a heaptuple only to have logical decoding grab individual attrs from there didn't sound terribly optimal. > I don't think there's anything missing in the slot interface itself, > but using slots probably would require some careful considerations > around memory management, possibly a decoding specific slot > implementation even. A specific slot implementation sounds like more work than I was envisioning. Can't we just "pin" a slot to a memory context or something like that, to keep it alive until decoding is done with it? It seems useful to avoid creating another copy of the tuple in memory (which we would need if, if I understand you correctly, we need to form the tuple under a different slot implementation from whatever the origin is). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
