distinguish versions

Author: yuuuxt

Dockerfile renamed to 12/Dockerfile

@@ -0,0 +1,27 @@
+# ref: https://github.com/docker-library/postgres/issues/340
+FROM postgres:13 AS extension_builder
+
+# Already download extension code
+RUN cd / && mkdir external_extensions && mkdir /external_extensions/sequential-uuids
+COPY lib/sequential-uuids/ /external_extensions/sequential-uuids/
+WORKDIR /external_extensions/sequential-uuids/
+
+# additional: change sources.list, but postgres source is still slow. don't need if proxy is used.
+# RUN echo "deb http://mirrors.tuna.tsinghua.edu.cn/debian/ buster main contrib non-free" > /etc/apt/sources.list
+# RUN echo "deb http://mirrors.tuna.tsinghua.edu.cn/debian/ buster-updates main contrib non-free" >> /etc/apt/sources.list
+# RUN echo "deb http://mirrors.tuna.tsinghua.edu.cn/debian/ buster-backports main contrib non-free" >> /etc/apt/sources.list
+# RUN echo "deb http://mirrors.tuna.tsinghua.edu.cn/debian-security buster/updates main contrib non-free" >> /etc/apt/sources.list
+
+
+RUN apt-get update && apt install build-essential libicu-dev postgresql-server-dev-all -y --no-install-recommends
+RUN make clean && make install
+
+FROM postgres:13
+#if use alpine: the paths are different!
+
+# run find / -name 'sequential_uuids*' to find newly compiled files and copy to next stage
+COPY --from=extension_builder /usr/lib/postgresql/13/lib /usr/lib/postgresql/13/lib
+COPY --from=extension_builder /usr/share/postgresql/13/extension /usr/share/postgresql/13/extension
+
+# after in sql:
+# CREATE EXTENSION sequential_uuids;

lib/sequential-uuids/.gitignore renamed to 12/lib/sequential-uuids/.gitignore

@@ -0,0 +1,2 @@
+*.o
+*.so

lib/sequential-uuids/LICENSE renamed to 12/lib/sequential-uuids/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2018 Tomas Vondra
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

lib/sequential-uuids/META.json renamed to 12/lib/sequential-uuids/META.json

@@ -0,0 +1,35 @@
+{
+   "name": "sequential_uuids",
+   "abstract": "UUID generators with sequential patterns, which helps to reduce random I/O patterns associated with regular entirely-random UUID.",
+   "description": "Regular random UUIDs are distributed uniformly over the whole range of possible values. This results in poor locality when inserting data into indexes - all index leaf pages are equally likely to be hit, forcing the whole index into memory. With small indexes that's fine, but once the index size exceeds shared buffers (or RAM), the cache hit ratio quickly deteriorates. The main goal of the two generators implemented by this extension, is generating UUIDS in a more sequential pattern, but without reducing the randomness too much (which could increase the probability of collision and predictability of the generated UUIDs). This idea is not new, and is described as",
+   "version": "1.0.1",
+   "maintainer": "Tomas Vondra <[email protected]>",
+   "license": "bsd",
+   "prereqs": {
+      "runtime": {
+         "requires": {
+            "PostgreSQL": "10.0.0"
+         }
+      }
+   },
+   "provides": {
+     "sequential_uuids": {
+       "file": "sequential_uuids--1.0.1.sql",
+       "docfile" : "README.md",
+       "version": "1.0.1"
+     }
+   },
+   "resources": {
+      "repository": {
+        "url":  "https://github.com/tvondra/sequential-uuids.git",
+        "web":  "http://github.com/tvondra/sequential-uuids",
+        "type": "git"
+      }
+   },
+   "tags" : ["UUID", "generator"],
+   "meta-spec": {
+      "version": "1.0.0",
+      "url": "http://pgxn.org/meta/spec.txt"
+   },
+   "release_status" : "stable"
+}

lib/sequential-uuids/Makefile renamed to 12/lib/sequential-uuids/Makefile

@@ -0,0 +1,19 @@
+# sequeantial_uuids/Makefile
+#
+# Copyright (c) 2014 Citus Data, Inc.
+#
+
+MODULE_big = sequential_uuids
+
+OBJS = sequential_uuids.o
+
+EXTENSION = sequential_uuids
+DATA = sequential_uuids--1.0.1.sql
+
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+
+ifndef MAJORVERSION
+    MAJORVERSION := $(basename $(VERSION))
+endif

lib/sequential-uuids/README.md renamed to 12/lib/sequential-uuids/README.md

@@ -0,0 +1,105 @@
+Sequential UUID generators
+==========================
+
+This PostgreSQL extension implements two UUID generators with sequential
+patterns, which helps to reduce random I/O patterns associated with
+regular entirely-random UUID.
+
+Regular random UUIDs are distributed uniformly over the whole range of
+possible values.  This results in poor locality when inserting data into
+indexes - all index leaf pages are equally likely to be hit, forcing
+the whole index into memory.  With small indexes that's fine, but once
+the index size exceeds shared buffers (or RAM), the cache hit ratio
+quickly deteriorates.
+
+Compare this to sequences and timestamps, which have a more sequential
+pattern and the new data almost always end up in the right-most part of
+the index (new sequence value is larger than all preceding values, same
+for timestamp).  This results in a nicer and cache-friendlier behavior,
+but the values are predictable and may easily collide cross machines.
+
+The main goal of the two generators implemented by this extension, is
+generating UUIDS in a more sequential pattern, but without reducing the
+randomness too much (which could increase the probability of collision
+and predictability of the generated UUIDs).  This idea is not new, and
+is described as 
+
+This idea is pretty much what the UUID wikipedia article [1] calls COMB
+(combined-time GUID) and is more more thoroughly explained in [2].
+
+
+Generators
+----------
+
+The extension provides two functions generating sequential UUIDs using
+either a sequence or timestamp.
+
+* `uuid_sequence_nextval(sequence regclass, block_size int default 65536, block_count int default 65536)`
+
+* `uuid_time_nextval(interval_length int default 60, interval_count int default 65536) RETURNS uuid`
+
+The default values for parameters are selected to work well for a range
+of workloads.  See the next section explaining the design for additional
+information about the meaning of those parameters.
+
+
+Design
+------
+
+The easiest way to make UUIDs more sequential is to use some sequential
+value as a prefix. For example, we might take a sequence or a timestamp
+and add random data until we have 16B in total.  The resulting values
+would be almost perfectly sequential, but there are two issues with it:
+
+* reduction of randomness - E.g. with a sequence producing bigint values
+  this would reduce the randomness from 16B to 8B.  Timestamps do reduce
+  the randomness in a similar way, depending on the accuracy.  This
+  increases both the collision probability and predictability (e.g. it
+  allows determining which UUIDs were generated close to each other, and
+  perhaps the exact timestamp).
+
+* bloat - If the values only grow, this may result in bloat in indexes
+  after deleting historical data.  This is a well-known issue e.g. with
+  indexes on timestamps in log tables.
+
+To address both of these issues, the implemented generators are designed
+to wrap-around regularly, either after generating certain number of UUIDs
+or some amount of time.  In both cases, the UUIDs are generates in blocks
+and have the form of
+
+    (block ID; random data)
+
+The size of the block ID depends on the number of blocks and is fixed
+(depends on generator parameters).  For example with the default 64k
+blocks we need 2 bytes to store it.  The block ID increments regularly,
+and eventually wraps around.
+
+For sequence-based generators the block size is determined by number of
+UUIDs generated.  For example we may use blocks of 256 values, in which
+case the two-byte block ID may be computed like this:
+
+    (nextval('s') / 256) % 65536
+
+So the generator wraps-around every ~16M UUIDs (because 256 * 65536).
+
+For timestamp-based generators, the block size is defined as interval
+length, with the default value 60 seconds.  As the default number of
+blocks is 64k (same as for sequence-based generators), the bloc may be
+computed like this
+
+    (timestamp / 60) % 65536
+
+Which means the generator wraps around every ~45 days.
+
+
+Supported Releases
+------------------
+
+Currently, this extension works only on releases since PostgreSQL 10. It
+can be made working on older releases with some minor code tweaks if
+someone wants to spend a bit of time on that.
+
+
+[1] https://en.wikipedia.org/wiki/Universally_unique_identifier
+
+[2] http://www.informit.com/articles/article.aspx?p=25862

lib/sequential-uuids/sequential_uuids--1.0--1.0.1.sql renamed to 12/lib/sequential-uuids/sequential_uuids--1.0--1.0.1.sql

@@ -0,0 +1,12 @@
+/* sequential_uuids.sql */
+
+-- complain if script is sourced in psql, rather than via CREATE EXTENSION
+\echo Use "CREATE EXTENSION sequential_uuids" to load this file. \quit
+
+CREATE FUNCTION uuid_sequence_nextval(regclass, block_size int default 65536, block_count int default 65536) RETURNS uuid
+AS 'MODULE_PATHNAME', 'uuid_sequence_nextval'
+LANGUAGE C STRICT PARALLEL SAFE;
+
+CREATE FUNCTION uuid_time_nextval(interval_length int default 60, interval_count int default 65536) RETURNS uuid
+AS 'MODULE_PATHNAME', 'uuid_time_nextval'
+LANGUAGE C STRICT PARALLEL SAFE;