Re: Cleaning up PREPARE query strings? - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Cleaning up PREPARE query strings?
Date
Msg-id CAA5RZ0sU-XUaGAATHhNZ-85u5h8SSbw0ykBPdBjOK-YXQkoy6g@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up PREPARE query strings?  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Cleaning up PREPARE query strings?
List pgsql-hackers
> ISTM that your proposal will actually use more memory because
> pstate->p_sourcetext does not get free'd, but we must now allocate
> space for a new "cleaned" query.

I'm not sure that I understand.  Sure we allocate a new temporary buffer for
the cleaned up query string but this will be freed soon.  The query string
stored in the prepared statement will stay in memory as long as the prepare
statement exist so this any cleanup can actually save a lot of memory.

My point is pstate->p_sourcetext doesn't get freed just because we're not
referencing it from CachedPlanSource in prepared_queries. Instead, with
multi-statement strings, prepared_queries now use a newly allocated string,
new_query, which will be around until DEALLOCATE.

```
+               tmp = palloc(rawstmt->stmt_len + 1);
+               strlcpy(tmp, cleaned, rawstmt->stmt_len + 1);
+
+               new_query = tmp;
```

So this patch always increases memory usage for multi-statement strings;
we have both the original multi-statement string and the cleaned up copy
around.

--
Sami Imseih
Amazon Web Services (AWS)

pgsql-hackers by date:

Previous
From: Filip Janus
Date:
Subject: Re: Proposal: Adding compression of temporary files
Next
From: Kirill Reshke
Date:
Subject: Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object