< 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.
- add some additional files to the dbmirror install (approved by
ssinger)
- add a makefile for contrib/mysql, and add mysql to the list of
contribs build by default
- use xml2-config to pickup -I flags for libxml2 in contrib/xml and
contrib/xml2
Original work from Martin Pitt of Debian, minor cleanups by Neil
Conway.
< * Use bitmaps to combine existing indexes [performance]
> * Allow the creation of bitmap indexes which can be quickly combined
> with other bitmap indexes
255,257c256,266
< Bitmap indexes allow single indexed columns to be combined to
< dynamically create a composite index to match a specific query. Each
< index is a bitmap, and the bitmaps are AND'ed or OR'ed to be combined.
> Bitmap indexes index single columns that can be combined with other bitmap
> indexes to dynamically create a composite index to match a specific query.
> Each index is a bitmap, and the bitmaps are bitwise AND'ed or OR'ed to be
> 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.
>
> * Allow non-bitmap indexes to be combined
>
> Do lookups on non-bitmap indexes and create bitmaps in memory that can be
> combined with other indexes.
< This perhaps should use a round-robin allocation system where several
< tablespaces are used in a cycle. The cycle pointer should be global.
> It could start with a random tablespace from a supplied list and cycle
> through the list.
< * Add a GUC variable to control the tablespace for temporary objects
> * Add a GUC variable to control the tablespace for temporary objects and
> sort files
>
> This perhaps should use a round-robin allocation system where several
> tablespaces are used in a cycle. The cycle pointer should be global.
>
to DAY precision or coarser; leave the timezone alone when precision is
HOUR or less. This avoids surprises for inputs near a DST transition
time, as per example from Matthew Gabeler-Lee. (The only reason we
recalculate at all is so that outputs that are supposed to represent
days will come out as local midnight, and that's not relevant for sub-day
precision.)
use it, as per my proposal of yesterday. This gives us a means of
determining the zone offset to impute to an unlabeled timestamp that
is both efficient and reliable, unlike all our previous tries involving
mktime() and localtime(). The behavior for invalid or ambiguous times
at a DST transition is fixed to be really and truly "assume standard
time", fixing a bug that has come and gone repeatedly but was back
again in 7.4. (There is some ongoing discussion about whether we should
raise an error instead, but for the moment I'll make it do what it was
previously intended to do.)
interesting for MS to catch all those dumps...
Anyway. Oops. Seems I ran my regression tests with the old psql, and
just managed to update the backend, when I tested that patch. Turns out
there are codepaths where we'd access the Critical Section before it was
initialized. Attached patch breaks the initializeation off to a separate
part and adds that one to a much earlier position in the program.
Magnus Hagander
of psql; this should make it easier to diagnose client-side problems,
such as library version mismatch. Also, consistently use -X option
to avoid problems from weird .psqlrc settings.
Use this new function in psql. Implement query cancellation in psql for
Windows. Code by Magnus Hagander, documentation and minor editorialization
by Tom Lane.
of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple:
if the row was updated or deleted by a subtransaction of my own transaction
that was later rolled back. This cannot occur in pre-8.0 of course, so
the hint-bit patch applied a couple weeks ago is OK for existing releases.
But for 8.0 it seems we had better fix things so that RI_FKey_check can
pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly,
add fields to the TriggerData struct to carry the buffer ID(s) for the
old and new tuple(s). There are other possible solutions but this one
seems cleanest; it will allow other AFTER-trigger functions to safely
do tqual.c calls if they want to. Put new fields at end of struct so
that there is no API breakage.
We can't regurgitate the unconverted string as I first thought, because
the elog.c mechanisms will assume the error message data is in the server
encoding and attempt a reverse conversion. Eventually it might be worth
providing a short-circuit path to support this, but for now the simplest
solution is to abandon trying to report back the line contents after a
conversion failure. Per bug report from Sil Lee, 27-Oct-2004.
'recycled log files' and 'removed log files' messages from DEBUG1 to
DEBUG2, replacing them with a count of files added/removed/recycled in
the checkpoint end message, as per suggestion from Simon Riggs.
Peter Eisentraut
Bruce Momjian
Tom Lane
Neil Conway
Dave Cramer