Fix planner statistics and manages query plans

Fork

Add subsidiary functions to tweak dummy statistics.

pg_statictics has some columns of anyarray which cannot be updated
through ordinary SQL statements and dbms_stats.column_stats_locked
inherits the characteristic. Though, it is inconvenient for those who
wants to tweak statistics, especially MCV, HISTOGRAM and like which
are of anyarray type.

This commit adds some functions to handle dbms_stats.anyarray to
enable them to write dummy (locked) statistics by hand.

Anyarray values can be updated by steps like following.

=# SELECT dbms_stats.anyarray_basetype(stavalues1)
FROM dbms_stats.column_stats_locked
WHERE starelid = xxxx AND staattnum = x;
anyarray_basetype
-------------------
float4
(1 row)
=# SELECT dbms_stats.prepare_statstweak('float4');
-------------------------------------------------------------------------------
----
(func dbms_stats._realary_anyarray(real[]), cast (real[] AS dbms_stats.anyarra
y))
(1 row)
=# UPDATE dbms_stats.column_stats_locked
SET stavalues1 = '{1.1,2.2,3.3}'::float4[]
WHERE starelid = xxxx AND staattnum = x;
UPDATE 1

Support for 9.4 added officially.

Since PostgreSQL REL9_4_0 has been released, pg_dbms_stats became to
support 9.4. There's no functional change made and some fixes in the
steps to build RPM packages has been made.

Add subsidiary functions to tweak dummy statistics.

pg_statictics has some columns of anyarray which cannot be updated
through ordinary SQL statements and dbms_stats.column_stats_locked
inherits the characteristic. Though, it is inconvenient for those who
wants to tweak statistics, especially MCV, HISTOGRAM and like which
are of anyarray type.

This commit adds some functions to handle dbms_stats.anyarray to
enable them to write dummy (locked) statistics by hand.

Anyarray values can be updated by steps like following.

=# SELECT dbms_stats.anyarray_basetype(stavalues1)
FROM dbms_stats.column_stats_locked
WHERE starelid = xxxx AND staattnum = x;
anyarray_basetype
-------------------
float4
(1 row)
=# SELECT dbms_stats.prepare_statstweak('float4');
-------------------------------------------------------------------------------
----
(func dbms_stats._realary_anyarray(real[]), cast (real[] AS dbms_stats.anyarra
y))
(1 row)
=# UPDATE dbms_stats.column_stats_locked
SET stavalues1 = '{1.1,2.2,3.3}'::float4[]
WHERE starelid = xxxx AND staattnum = x;
UPDATE 1

Fix release date of 1.3.6 in SPEC files.

Fixed regression tests to avoid test failure for 9.1.

A test item added in ut-common at 1.3.5 failed for 9.1 because the
error message differs from later versions. Moved it to
version-specific tests.

Fixed import function according to the current stats table
configuration.

The stats tables prefixed by underscore have been removed in the last
release, but import function did not follow that change. It results in
failure of import_xxx_stats() for dump files of any version including
itself.

Fix target version of 9.4 regtests, which was no harm.

Prepare for 1.3.6

Change release number of spec files to 2.

The previous release was based on the funcion-version of
HeapTupleGetDatum() so they cannot be loaded on the minor versions
earlier than 9.1.14, 9.2.9 and 9.3.5 with link failure of
HeapTupleHeaderGetDatum.

I confirmed that the commit(*1) does not affect pg_dbms_stats and
decided to build rpm releases on 9.1.13, 9.2.8 and 9.3.4 after this.

There has been one bug after 1.3.5 was released but it is a bug in
error message of rarely used SQL function so no increment of version
number.

*1: d3c9f9c5b57d2a8a7ab065a6b942703854ec5e97 for 9.1
315442c01156d4f6c0f766ec51da090a613d03b8 for 9.2
edde59db1339397ec389d45e4c0d0f86064dad1a for 9.3
621a99a666ba1a27b852dc5ddc0e1b224c388f53 on master branch

Fix exception messages.

Exception messages in definitions of dbms_stats.restore(bid, relname,
colname) were incorrect. This causes incomprehensive message like this,

ERROR: too many parameters specified for RAISE

There's no harm other than the bogus message.

Edit ChangeLogs. Fixed some misspellings.

Correct permission of dummy statistics tables.

On the current implement, when planner requested the statistics
for a column, pg_dbms_stats takes it from the dummy statistics
tables via views which gives stats only of columns that the
current user can SELECT.
Under that way of restriction, pg_dbms_stats cannot read the
dummy statistcs of objects invisible from the current user so
accessing such objects via views will done using system
statistics, even if their statistics are locked.
This commit makes the dummy stats tables visible only by the
owner, then makes pg_dbms_stats access the dummy statistics as
the owner. It also changes the visibility/usability of some other
objects such as dbms_stats schema, some functions as a result.

Fix and modify regression test.

The delay of stats collector is expected up to 0.5s so 0.5s is not
enough for waiting.

Make environment for 1.3.5

Update RPM release number to 2.

default_version of pg_dbms_stats.control is corrected.

Version 1.3.4

Fix a bug that faultily invalidates stored stats for inheritance parents.

Internal on-memory cache mechanism wrongly handled stainherit
flag. This is resulted in a false response for inheritance parents,
which let the planner use the real statistic instead of the stored
one.

Edit RPM spacfiles and ChangeLogs

Fix a bug which potentially returns wrong statsitc tuple from internal
cache.

Altough Relation statistics cache has the key of relation id and it is
expected to hash and match it as oid, the cache control data was
created withOUT HASH_FUNCTION flag for hash_create(). This causes a
false match between oids having a intermediate 0x00 byte and identical
lower bytes (as for little endian). Returning the wrong statistics
cache can result in server crash, or at least getting unexpected
plans.

Raise granularity of locks.

Almost all sql functions of pg_dbms_stats takes "share update
exclusive" locks on internal tables before they does their work. As
the result, it serializes dbms_stats operations even if they're on
different tables. This commit replaces such giant locks with the more
narrowed locks so that operations on different tables basically can
run in parallel. As the exchange for the concurrency, multiple (first
time) statistics lock operations on the same table at the same time
may result in failure of either of them. But it does no matter under
usual usage.

Change inappropreate variable name.

Correct wordings in comments.

Remove unnecessary 'OR REPLACE' from sql function definitions.

Stablize regtest.

Previous regression tests are unstable for repetitive execution.

These instability comes from mainly from unwanted auto vacuums and
locks unrelated to the test. So fix these factors of the instability
and tidied up the code.

Rewrite error messages. Fix some typos in comments.

Rearrange files for 1.3.3

Rearrange files

Add instruction for installcheck.

Add gtags files to .gitignore.