change saves a great deal of space in pg_proc and its primary index,
and it eliminates the former requirement that INDEX_MAX_KEYS and
FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded
in the on-disk representation (because it affects index tuple header
size), but FUNC_MAX_ARGS is not. I believe it would now be possible
to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet.
There are still a lot of vestigial references to FUNC_MAX_ARGS, which
I will clean up in a separate pass. However, getting rid of it
altogether would require changing the FunctionCallInfoData struct,
and I'm not sure I want to buy into that.
access: define new index access method functions 'amgetmulti' that can
fetch multiple TIDs per call. (The functions exist but are totally
untested as yet.) Since I was modifying pg_am anyway, remove the
no-longer-needed 'rel' parameter from amcostestimate functions, and
also remove the vestigial amowner column that was creating useless
work for Alvaro's shared-object-dependencies project.
Initdb forced due to changes in pg_am.
executing a statement that fires triggers. Formerly this time was
included in "Total runtime" but not otherwise accounted for.
As a side benefit, we avoid re-opening relations when firing non-deferred
AFTER triggers, because the trigger code can re-use the main executor's
ResultRelInfo data structure.
currently does. This is now the default Win32 wal sync method because
we perfer o_datasync to fsync.
Also, change Win32 fsync to a new wal sync method called
fsync_writethrough because that is the behavior of _commit, which is
what is used for fsync on Win32.
Backpatch to 8.0.X.
< * Add ANSI INTERVAL handling
> * Add ISo INTERVAL handling
< o Interpret syntax that isn't uniquely ANSI or PG, like '1:30' or
< '1' as ANSI syntax, e.g. interpret '1:30' MINUTE TO SECOND as
> o Interpret syntax that isn't uniquely ISO or PG, like '1:30' or
> '1' as ISO syntax, e.g. interpret '1:30' MINUTE TO SECOND as
649c649
< * Add pre-parsing phase that converts non-ANSI syntax to supported
> * Add pre-parsing phase that converts non-ISO syntax to supported
< o Process mixed ANSI/PG syntax, and round value to requested
< precision or generate an error
< o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
< INTERVAL MONTH), and this should return '12 months'
194a191,194
> o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
> INTERVAL MONTH), and this should return '12 months'
> o Round or truncate values to the requested precision, e.g.
> INTERVAL '11 months' AS YEAR should return one or zero
< o Add support for day-time syntax, INTERVAL '1 2:03:04'
> o Add support for day-time syntax, INTERVAL '1 2:03:04'
192c192,194
< o Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> o Interpret syntax that isn't uniquely ANSI or PG, like '1:30' or
> '1' as ANSI syntax, e.g. interpret '1:30' MINUTE TO SECOND as
> '1 minute 30 seconds'
< * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO SECOND
< * Add support for ANSI date INTERVAL syntax, INTERVAL '20-6' YEAR TO MONTH
< * Process mixed ANSI/PG INTERVAL syntax, and round value to requested precision
<
< Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS INTERVAL
< MONTH), and this should return '12 months'
<
< * Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> * Add ANSI INTERVAL handling
> o Add support for day-time syntax, INTERVAL '1 2:03:04'
> DAY TO SECOND
> o Add support for year-month syntax, INTERVAL '50-6' YEAR TO MONTH
> o Process mixed ANSI/PG syntax, and round value to requested
> precision or generate an error
> o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
> INTERVAL MONTH), and this should return '12 months'
> o Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> o Support precision, CREATE TABLE foo (a INTERVAL MONTH(3))
< * Add support for ANSI date INTERVAL syntax, INTERVAL '9-3' YEAR TO MONTH
> * Add support for ANSI date INTERVAL syntax, INTERVAL '20-6' YEAR TO MONTH
< * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
> * Add support for ANSI date INTERVAL syntax, INTERVAL '9-3' YEAR TO MONTH
ExclusiveLock rather than AccessExclusiveLock. This will allow concurrent
SELECT queries to proceed on the table. Per discussion with Andrew at
SuperNews.
> * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO SECOND
> * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
> * Process mixed ANSI/PG INTERVAL syntax, and round value to requested precision
184a188,189
> Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS INTERVAL
> MONTH), and this should return '12 months'
>
> * Support table partitioning that allows a single table to be stored
> in subtables that are partitioned based on the primary key or a WHERE
> clause
convention for isnull flags. Also, remove the useless InsertIndexResult
return struct from index AM aminsert calls --- there is no reason for
the caller to know where in the index the tuple was inserted, and we
were wasting a palloc cycle per insert to deliver this uninteresting
value (plus nontrivial complexity in some AMs).
I forced initdb because of the change in the signature of the aminsert
routines, even though nothing really looks at those pg_proc entries...
< SQL-spec compliant, so allow such handling to be disabled.
> SQL-spec compliant, so allow such handling to be disabled. However,
> disabling backslashes could break many third-party applications and tools.
of tuples when passing data up through multiple plan nodes. A slot can now
hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting
of Datum/isnull arrays. Upper plan levels can usually just copy the Datum
arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr()
calls to extract the data again. This work extends Atsushi Ogawa's earlier
patch, which provided the key idea of adding Datum arrays to TupleTableSlots.
(I believe however that something like this was foreseen way back in Berkeley
days --- see the old comment on ExecProject.) A test case involving many
levels of join of fairly wide tables (about 80 columns altogether) showed
about 3x overall speedup, though simple queries will probably not be
helped very much.
I have also duplicated some code in heaptuple.c in order to provide versions
of heap_formtuple and friends that use "bool" arrays to indicate null
attributes, instead of the old convention of "char" arrays containing either
'n' or ' '. This provides a better match to the convention used by
ExecEvalExpr. While I have not made a concerted effort to get rid of uses
of the old routines, I think they should be deprecated and eventually removed.
< o Disallow encodings like UTF8 which PostgreSQL supports
< but the operating system does not (already disallowed by
< pginstaller)
> o Add support for Unicode
< To fix UTF8, the data needs to be converted to UTF16 and then
< the Win32 wcscoll() can be used, and perhaps other functions
> To fix this, the data needs to be converted to/from UTF16/UTF8
> so the Win32 wcscoll() can be used, and perhaps other functions
< locales but provides no ordering.
<
> locales but provides no ordering or character set classes.
whether or not it is a security definer. Changing a function's strictness
is required by SQL2003, and the other capabilities make sense. Also, allow
an optional RESTRICT noise word to be specified, for SQL conformance.
Some trivial regression tests added and the documentation has been
updated.
can tell whether it is being used as an aggregate or not. This allows
such a function to avoid re-pallocing a pass-by-reference transition
value; normally it would be unsafe for a function to scribble on an input,
but in the aggregate case it's safe to reuse the old transition value.
Make int8inc() do this. This gets a useful improvement in the speed of
COUNT(*), at least on narrow tables (it seems to be swamped by I/O when
the table rows are wide). Per a discussion in early December with
Neil Conway. I also fixed int_aggregate.c to check this, thereby
turning it into something approaching a supportable technique instead
of being a crude hack.
Formerly, if such a clause contained no aggregate functions we mistakenly
treated it as equivalent to WHERE. Per spec it must cause the query to
be treated as a grouped query of a single group, the same as appearance
of aggregate functions would do. Also, the HAVING filter must execute
after aggregate function computation even if it itself contains no
aggregate functions.
the freelist, plus per-buffer spinlocks that protect access to individual
shared buffer headers. This requires abandoning a global freelist (since
the freelist is a global contention point), which shoots down ARC and 2Q
as well as plain LRU management. Adopt a clock sweep algorithm instead.
Preliminary results show substantial improvement in multi-backend situations.
adjusting values:
> But to be on the safe side, it would make sense to do something similar
> to the BSD section, and comment about older distributions maybe needing
> to manipulate /proc/kernel/* directly.
Mark Kirkwood
! authentication. Use of this environment variable is not
! recommended for security reasons (some operating systems
! allow non-root users to see process environment variables via
! <application>ps</>); instead consider using the
! <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">).