2010-09-21 04:08:53 +08:00
|
|
|
# contrib/hstore/Makefile
|
2007-02-10 01:04:00 +08:00
|
|
|
|
2006-09-06 02:00:58 +08:00
|
|
|
MODULE_big = hstore
|
2019-11-06 06:41:07 +08:00
|
|
|
OBJS = \
|
|
|
|
|
$(WIN32RES) \
|
|
|
|
|
hstore_compat.o \
|
|
|
|
|
hstore_gin.o \
|
|
|
|
|
hstore_gist.o \
|
|
|
|
|
hstore_io.o \
|
|
|
|
|
hstore_op.o
|
2006-09-06 02:00:58 +08:00
|
|
|
|
2011-02-14 09:06:41 +08:00
|
|
|
EXTENSION = hstore
|
2018-11-24 02:37:34 +08:00
|
|
|
DATA = hstore--1.4.sql \
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-31 00:17:11 +08:00
|
|
|
hstore--1.6--1.7.sql \
|
2018-11-24 02:37:34 +08:00
|
|
|
hstore--1.5--1.6.sql \
|
|
|
|
|
hstore--1.4--1.5.sql \
|
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 23:12:39 +08:00
|
|
|
hstore--1.3--1.4.sql hstore--1.2--1.3.sql \
|
2020-02-20 05:59:14 +08:00
|
|
|
hstore--1.1--1.2.sql hstore--1.0--1.1.sql
|
2014-07-15 02:07:52 +08:00
|
|
|
PGFILEDESC = "hstore - key/value pair data type"
|
2011-02-14 09:06:41 +08:00
|
|
|
|
2018-08-01 02:58:39 +08:00
|
|
|
HEADERS = hstore.h
|
|
|
|
|
|
2006-09-06 02:00:58 +08:00
|
|
|
REGRESS = hstore
|
|
|
|
|
|
2011-01-24 12:07:55 +08: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-06 02:00:58 +08:00
|
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
2011-01-24 12:07:55 +08:00
|
|
|
endif
|
