2010-09-21 00:08:53 +04:00
|
|
|
# contrib/hstore/Makefile
|
2007-02-09 20:04:00 +03:00
|
|
|
|
2006-09-05 22:00:58 +04:00
|
|
|
MODULE_big = hstore
|
2009-09-30 23:50:22 +04:00
|
|
|
OBJS = hstore_io.o hstore_op.o hstore_gist.o hstore_gin.o hstore_compat.o \
|
Switch to CRC-32C in WAL and other places.
The old algorithm was found to not be the usual CRC-32 algorithm, used by
Ethernet et al. We were using a non-reflected lookup table with code meant
for a reflected lookup table. That's a strange combination that AFAICS does
not correspond to any bit-wise CRC calculation, which makes it difficult to
reason about its properties. Although it has worked well in practice, seems
safer to use a well-known algorithm.
Since we're changing the algorithm anyway, we might as well choose a
different polynomial. The Castagnoli polynomial has better error-correcting
properties than the traditional CRC-32 polynomial, even if we had
implemented it correctly. Another reason for picking that is that some new
CPUs have hardware support for calculating CRC-32C, but not CRC-32, let
alone our strange variant of it. This patch doesn't add any support for such
hardware, but a future patch could now do that.
The old algorithm is kept around for tsquery and pg_trgm, which use the
values in indexes that need to remain compatible so that pg_upgrade works.
While we're at it, share the old lookup table for CRC-32 calculation
between hstore, ltree and core. They all use the same table, so might as
well.
2014-11-04 12:35:15 +03:00
|
|
|
$(WIN32RES)
|
2006-09-05 22:00:58 +04:00
|
|
|
|
2011-02-14 04:06:41 +03:00
|
|
|
EXTENSION = hstore
|
Distinguish selectivity of < from <= and > from >=.
Historically, the selectivity functions have simply not distinguished
< from <=, or > from >=, arguing that the fraction of the population that
satisfies the "=" aspect can be considered to be vanishingly small, if the
comparison value isn't any of the most-common-values for the variable.
(If it is, the code path that executes the operator against each MCV will
take care of things properly.) But that isn't really true unless we're
dealing with a continuum of variable values, and in practice we seldom are.
If "x = const" would estimate a nonzero number of rows for a given const
value, then it follows that we ought to estimate different numbers of rows
for "x < const" and "x <= const", even if the const is not one of the MCVs.
Handling this more honestly makes a significant difference in edge cases,
such as the estimate for a tight range (x BETWEEN y AND z where y and z
are close together).
Hence, split scalarltsel into scalarltsel/scalarlesel, and similarly
split scalargtsel into scalargtsel/scalargesel. Adjust <= and >=
operator definitions to reference the new selectivity functions.
Improve the core ineq_histogram_selectivity() function to make a
correction for equality. (Along the way, I learned quite a bit about
exactly why that function gives good answers, which I tried to memorialize
in improved comments.)
The corresponding join selectivity functions were, and remain, just stubs.
But I chose to split them similarly, to avoid confusion and to prevent the
need for doing this exercise again if someone ever makes them less stubby.
In passing, change ineq_histogram_selectivity's clamp for extreme
probability estimates so that it varies depending on the histogram
size, instead of being hardwired at 0.0001. With the default histogram
size of 100 entries, you still get the old clamp value, but bigger
histograms should allow us to put more faith in edge values.
Tom Lane, reviewed by Aleksander Alekseev and Kuntal Ghosh
Discussion: https://postgr.es/m/12232.1499140410@sss.pgh.pa.us
2017-09-13 18:12:39 +03:00
|
|
|
DATA = hstore--1.4.sql hstore--1.4--1.5.sql \
|
|
|
|
|
hstore--1.3--1.4.sql hstore--1.2--1.3.sql \
|
Introduce jsonb, a structured format for storing json.
The new format accepts exactly the same data as the json type. However, it is
stored in a format that does not require reparsing the orgiginal text in order
to process it, making it much more suitable for indexing and other operations.
Insignificant whitespace is discarded, and the order of object keys is not
preserved. Neither are duplicate object keys kept - the later value for a given
key is the only one stored.
The new type has all the functions and operators that the json type has,
with the exception of the json generation functions (to_json, json_agg etc.)
and with identical semantics. In addition, there are operator classes for
hash and btree indexing, and two classes for GIN indexing, that have no
equivalent in the json type.
This feature grew out of previous work by Oleg Bartunov and Teodor Sigaev, which
was intended to provide similar facilities to a nested hstore type, but which
in the end proved to have some significant compatibility issues.
Authors: Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan.
Review: Andres Freund
2014-03-24 00:40:19 +04:00
|
|
|
hstore--1.1--1.2.sql hstore--1.0--1.1.sql \
|
2013-09-30 06:46:55 +04:00
|
|
|
hstore--unpackaged--1.0.sql
|
2014-07-14 22:07:52 +04:00
|
|
|
PGFILEDESC = "hstore - key/value pair data type"
|
2011-02-14 04:06:41 +03:00
|
|
|
|
2018-07-31 21:58:39 +03:00
|
|
|
HEADERS = hstore.h
|
|
|
|
|
|
2023-06-12 03:14:20 +03:00
|
|
|
REGRESS = hstore hstore_utf8
|
2006-09-05 22:00:58 +04:00
|
|
|
|
2011-01-24 07:07:55 +03:00
|
|
|
ifdef USE_PGXS
|
|
|
|
|
PG_CONFIG = pg_config
|
|
|
|
|
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
|
|
|
|
include $(PGXS)
|
|
|
|
|
else
|
|
|
|
|
subdir = contrib/hstore
|
|
|
|
|
top_builddir = ../..
|
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
2006-09-05 22:00:58 +04:00
|
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
2011-01-24 07:07:55 +03:00
|
|
|
endif
|