Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries
| От | Fabien COELHO |
|---|---|
| Тема | Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries |
| Дата | |
| Msg-id | alpine.DEB.2.20.1701122004190.3788@lancre обсуждение исходный текст |
| Ответ на | Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries
|
| Список | pgsql-hackers |
About having a pointer to the initial string from RawStmt, Query & PlannedStmt: > I remembered one reason why we haven't done this: it's unclear how we'd > handle copying if we do it. If, say, Query contains a "char *" pointer > then you'd expect copyObject() to pstrdup that string, [..., So] We'd > need to work out a way of managing multiple Queries carrying references > to the same source string, and it's not clear how to do that reasonably. For me it would be shared, but then it may break some memory management hypothesis downstream. > So for now, it remains the path of least resistance for Portals and > CachedPlans to contain a list of Query or PlannedStmt objects and a > separate source string. Ok. Thanks for the explanation. -- Fabien.
В списке pgsql-hackers по дате отправления: