< portability issues. Anonymous mmap is required to prevent I/O
< overhead.
> portability issues. Anonymous mmap (or mmap to /dev/zero) is required
> to prevent I/O overhead.
>
> * Consider mmap()'ing files into a backend?
>
> Doing I/O to large tables would consume a lot of address space or
> require frequent mapping/unmapping. Extending the file also causes
> mapping problems that might require mapping only individual pages,
> leading to thousands of mappings. Another problem is that there is no
> way to _prevent_ I/O to disk from the dirty shared buffers so changes
> could hit disk before WAL is written.
estimates when combining the estimates for a range query. As pointed out
by Miquel van Smoorenburg, the existing check for an impossible combined
result would quite possibly fail to detect one default and one non-default
input. It seems better to use the default range query estimate in such
cases. To do so, add a check for an estimate of exactly DEFAULT_INEQ_SEL.
This is a bit ugly because it introduces additional coupling between
clauselist_selectivity and scalarltsel/scalargtsel, but it's not like
there wasn't plenty already...
< posix_fadvise() [fadvise]
> posix_fadvise()
>
> Posix_fadvise() can control both sequential/random file caching and
> free-behind behavior, but it is unclear how the setting affects other
> backends that also have the file open, and the feature is not supported
> on all operating systems.
>
Add explicit documentation of the recovery configuration settings. Other
minor improvements in the PITR docs. Simon Riggs, some editorialization
by Tom Lane.
< * CREATE TABLE AS can not determine column lengths from expressions [atttypmod]
> * Allow CREATE TABLE AS to determine column lengths for complex
> expressions like SELECT col1 || col2
< * Automatically create rules on views so they are updateable, per SQL99 [view]
> * Automatically create rules on views so they are updateable, per SQL99
>
> We can only auto-create rules for simple views. For more complex
> cases users will still have to write rules.
>
working as intended --- for some reason, FROM a.b.c was getting
parsed as if it were a function name and not a qualified name.
I think there must be a bug in bison, because it should have
complained that the grammar was ambiguous. Anyway, fix it along
the same lines previously used for func_name vs columnref, and get
rid of the right-recursion in attrs that seems to have confused
bison.
actual executable location. This allows people to continue to use
setups where, eg, postmaster is symlinked from a convenient place.
Per gripe from Josh Berkus.
type-and-length coercion function, make sure that the coercion function
is told the correct typmod. Fixes Kris Jurka's example of a domain
over bit(N).
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.
everywhere not just some places, get rid of . and .. when joining path
sections together. This should eliminate most of the ugly paths like
/foo/bar/./baz that we've been generating.
clause implicitly whenever one is not given explicitly. Remove concept
of a schema having an associated tablespace, and simplify the rules for
selecting a default tablespace for a table or index. It's now just
(a) explicit TABLESPACE clause; (b) default_tablespace if that's not an
empty string; (c) database's default. This will allow pg_dump to use
SET commands instead of tablespace clauses to determine object locations
(but I didn't actually make it do so). All per recent discussions.
< that can spam more than one table.
> that can span more than one table.
239c239
< rather than just col1
> rather than just col1; also called skip-scanning.
641c641,642
< * Add free-behind capability for large sequential scans [fadvise]
> * Allow free-behind capability for large sequential scans, perhaps using
> posix_fadvise() [fadvise]
< * Allow the creation of bitmap indexes which can be quickly combined
< with other bitmap indexes
> * Allow non-bitmap indexes to be combined by creating bitmaps in memory
259,261c258,259
< combined. Such indexes could be more compact if there are few unique
< value. Also, perhaps they can be lossy requiring a scan of the heap page
< to find matching rows.
> combined. They can index by tid or can be lossy requiring a scan of the
> heap page to find matching rows.
263c261,262
< * Allow non-bitmap indexes to be combined
> * Allow the creation of on-disk bitmap indexes which can be quickly
> combined with other bitmap indexes
265,266c264
< Do lookups on non-bitmap indexes and create bitmaps in memory that can be
< combined with other indexes.
> Such indexes could be more compact if there are few unique value.
