| From: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | [PATCH v1] add SQL type INT16 based on int128 |
| Date: | 2026-07-30 15:54:50 |
| Message-ID: | 4b204d7b6aefba8979f33656c4426224@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello hackers,
I would like to present a new contrib module that implements a 128-bit
signed integer type for PostgreSQL, called INT16.
The INT8 type was introduced in PostgreSQL more than 25 years ago, when
32-bit processors were replacing 16-bit processors, and 64-bit integer
support became widely available in compilers. Today we are seeing a
similar transition with 64-bit processors and native int128 support,
which is now present in all major compilers.
This patch implements an SQL INT16 type based on the existing C int128
type that PostgreSQL already uses internally for computations(see
src/include/common/int128.h). The extension was created because we
identified a real-world use case: some clients use NUMERIC(38,0) as
identifiers or codes rather than actual numeric values, and they rely
heavily on indexing and search operations on these columns.
The INT16 type offers several advantages over NUMERIC(38,0) for this
purpose:
- It is shorter (16 bytes vs. up to 20 bytes for numeric)
- Computations are faster, even when the compiler falls back to the
software-emulated int128 implementation
- Indexing and search operations are significantly faster because
comparisons do not involve memory allocation
Interestingly, we found that INT16 can replace numeric in many scenarios
where values never reach the 10^38 limit. For example, in the TPC-H
benchmark, price, quantity, and discount columns can be normalized by a
factor of 100 and stored as integers without losing precision.
At the recent PGConf.dev 2026, during the discussion about unsigned int
types, it was briefly mentioned that PostgreSQL might need a type
longer than 64-bit integer. In light of this, I am publishing
this extension as a starting point for discussion. While this code has
been used internally in production environments, we believe it may be
useful to a wider audience, and we would like to contribute it to the
PostgreSQL ecosystem.
The extension is implemented as a contrib module for easy testing.
However, in this form we cannot fully achieve all performance benefits
because casts to/from numeric currently go through text conversion,
which adds overhead. Ideally, the casting functions would be integrated
directly into numeric.c.
I hope this extension generates interest and that the code can be
considered for inclusion in the PostgreSQL core.
We have run TPC-H benchmarks at scale 100 with this type.
The bench is based on https://github.com/tvondra/pg_tpch.git .
The results are as follows (percent - query execution time
INT16 comparing to NUMERIC):
Faster - queries with many aggregate functions
Q1 63,04% 7 sum and avg
Q11 83,20% 3 sum
Q15 70,04% 2 sum and max
Q17 83,11% 2 sum and avg
Q18 70,22% 2 sum and
Q20 95,99% 1 sum
Similar performance:
Q2 109,87% 1 sum
Q7 102,25% 1 sum
Q8 102,00% 1 sum
Q9 99,92% 1 sum
Q14 102,89% 1 sum
Q19 100,27% 1 sum
Slower - queries build different plans:
Q5 278,88% Different query plans
Q6 239,75% Different query plans
Q10 176,05% Different query plans
Q22 122,36% Different query plans
Queries without numeric:
Q4,Q12,Q13,Q16, Q21 No numeric in query
Summary about functions.
The extension supports:
- Full arithmetic and comparison operators, including cross-type
operations with int2, int4, and int8
- B-tree and Hash indexes
- Aggregates: sum, avg, min, max
- Window function RANGE support via in_range()
- generate_series for int16
- Mathematical functions: gcd, lcm, factorial
- Parallel execution support
Limitations in the current contrib implementation:
- Casts from/to numeric are less efficient than they could be
- No GiST/GIN/SP-GiST/BRIN support
I would appreciate any feedback, especially regarding:
1. Performance characteristics and benchmark results
2. The casting interface between int16 and numeric
3. Whether the community sees value in promoting this type from contrib
to core
Looking forward to your thoughts.
--
Best regards,
Vladlen Popolitov.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-add-type-INT16.patch | text/x-diff | 217.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2026-07-30 16:45:34 | Re: [PATCH] Batched clock sweep to reduce cross-socket atomic contention |
| Previous Message | Ayoub Kazar | 2026-07-30 15:50:18 | Re: [PATCH] Rewrite undirected edge patterns in GRAPH_TABLE using UNION ALL |