diff options
| author | Andres Freund <andres@anarazel.de> | 2017-10-11 16:01:52 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2017-10-11 16:01:52 -0700 |
| commit | 1de09ad8eb1fa673ee7899d6dfbb2b49ba204818 (patch) | |
| tree | 9e4446d18d50f944a812d6fba7d1c2a085e5ce84 /src/backend/utils | |
| parent | 70c2d1be2b1e1efa8ef38a92b443fa290a9558dd (diff) | |
| download | postgresql-1de09ad8eb1fa673ee7899d6dfbb2b49ba204818.tar.gz postgresql-1de09ad8eb1fa673ee7899d6dfbb2b49ba204818.zip | |
Add more efficient functions to pqformat API.
There's three prongs to achieve greater efficiency here:
1) Allow reusing a stringbuffer across pq_beginmessage/endmessage,
with the new pq_beginmessage_reuse/endmessage_reuse. This can be
beneficial both because it avoids allocating the initial buffer,
and because it's more likely to already have an correctly sized
buffer.
2) Replacing pq_sendint() with pq_sendint$width() inline
functions. Previously unnecessary and unpredictable branches in
pq_sendint() were needed. Additionally the replacement functions
are implemented more efficiently. pq_sendint is now deprecated, a
separate commit will convert all in-tree callers.
3) Add pq_writeint$width(), pq_writestring(). These rely on sufficient
space in the StringInfo's buffer, avoiding individual space checks
& potential individual resizing. To allow this to be used for
strings, expose mbutil.c's MAX_CONVERSION_GROWTH.
Followup commits will make use of these facilities.
Author: Andres Freund
Discussion: https://postgr.es/m/20170914063418.sckdzgjfrsbekae4@alap3.anarazel.de
Diffstat (limited to 'src/backend/utils')
| -rw-r--r-- | src/backend/utils/mb/mbutils.c | 11 |
1 files changed, 0 insertions, 11 deletions
diff --git a/src/backend/utils/mb/mbutils.c b/src/backend/utils/mb/mbutils.c index c4fbe0903ba..56f4dc1453c 100644 --- a/src/backend/utils/mb/mbutils.c +++ b/src/backend/utils/mb/mbutils.c @@ -42,17 +42,6 @@ #include "utils/syscache.h" /* - * When converting strings between different encodings, we assume that space - * for converted result is 4-to-1 growth in the worst case. The rate for - * currently supported encoding pairs are within 3 (SJIS JIS X0201 half width - * kanna -> UTF8 is the worst case). So "4" should be enough for the moment. - * - * Note that this is not the same as the maximum character width in any - * particular encoding. - */ -#define MAX_CONVERSION_GROWTH 4 - -/* * We maintain a simple linked list caching the fmgr lookup info for the * currently selected conversion functions, as well as any that have been * selected previously in the current session. (We remember previous |