Commit Graph

20020 Commits

Author SHA1 Message Date
Tom Lane e092828241 Teach choose_bitmap_and() to actually be choosy --- that is, try to
make some estimate of which available indexes to AND together, rather
than blindly taking 'em all.  This could probably stand further
improvement, but it seems to do OK in simple tests.
2005-04-23 01:57:34 +00:00
Tom Lane 4b89126ccc Fix bogus EXPLAIN display of rowcount estimates for BitmapAnd and
BitmapOr nodes.
2005-04-23 01:29:15 +00:00
Tom Lane bc843d3960 First cut at planner support for bitmap index scans. Lots to do yet,
but the code is basically working.  Along the way, rewrite the entire
approach to processing OR index conditions, and make it work in join
cases for the first time ever.  orindxpath.c is now basically obsolete,
but I left it in for the time being to allow easy comparison testing
against the old implementation.
2005-04-22 21:58:32 +00:00
Bruce Momjian ccbb07d922 Fix typo:
<   Currently indexes do not have enough tuple tuple visibility
<   information to allow data to be pulled from the index without
<   also accessing the heap.  One way to allow this is to set a bit
<   to index tuples to indicate if a tuple is currently visible to
<   all transactions when the first valid heap lookup happens.  This
<   bit would have to be cleared when a heap tuple is expired.
>   Currently indexes do not have enough tuple visibility information
>   to allow data to be pulled from the index without also accessing
>   the heap.  One way to allow this is to set a bit to index tuples
>   to indicate if a tuple is currently visible to all transactions
>   when the first valid heap lookup happens.  This bit would have to
>   be cleared when a heap tuple is expired.
2005-04-22 15:40:16 +00:00
Bruce Momjian 6f61ddd40d Typo fix. Alvaro. 2005-04-22 15:32:58 +00:00
Bruce Momjian 8f4a1b3e84 Update URL for TODO list. 2005-04-22 13:38:19 +00:00
Bruce Momjian d76f279a55 Remove pre-7.3 mention that FOR UPDATE can be before LIMIT.
Document that FOR UPDATE and LIMIT together can return fewer rows that
LIMIT specifies, and why.
2005-04-22 04:20:44 +00:00
Bruce Momjian 26bb65df1e Clarify that only crypt can't use md5 pg_shadow passwords. 2005-04-22 04:18:58 +00:00
Bruce Momjian c82b895284 Clarify use of MD5 authentication and pg_shadow encryption. 2005-04-21 22:19:19 +00:00
Tom Lane 14c7fba3f7 Rethink original decision to use AND/OR Expr nodes to represent bitmap
logic operations during planning.  Seems cleaner to create two new Path
node types, instead --- this avoids duplication of cost-estimation code.
Also, create an enable_bitmapscan GUC parameter to control use of bitmap
plans.
2005-04-21 19:18:13 +00:00
Bruce Momjian c6221db3c0 Updated text for bitmaps:
<   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.  They can index by tid or can be lossy requiring a scan of the
<   heap page to find matching rows, or perhaps use a mixed solution where
<   tids are recorded for pages with only a few matches and per-page bitmaps
<   are used for more dense pages.  Another idea is to use a 32-bit bitmap
<   for every page and set a bit based on the item number mod(32).

>   This feature allows separate indexes to be ANDed or ORed together.  This
>   is particularly useful for data warehousing applications that need to
>   query the database in an many permutations.  This feature scans an index
>   and creates an in-memory bitmap, and allows that bitmap to be combined
>   with other bitmap created in a similar way.  The bitmap can either index
>   all TIDs, or be lossy, meaning it records just page numbers and each
>   page tuple has to be checked for validity in a separate pass.
2005-04-21 15:20:39 +00:00
Bruce Momjian 631e03145f Done:
< * Add tool to query pg_stat_* tables and report indexes that aren't needed
<   or tables that might need indexes
2005-04-21 04:09:34 +00:00
Tom Lane e6f7edb9d5 Install some slightly realistic cost estimation for bitmap index scans. 2005-04-21 02:28:02 +00:00
Tom Lane 2f8c7c866c Make pg_ctl status do a kill() test to verify that the PID found in
postmaster.pid still represents a live postmaster.
2005-04-20 23:10:16 +00:00
Tom Lane 1c155c8dfb Add note clarifying that indexes that support ordered scans had better
allow clauseless scans.
2005-04-20 22:19:58 +00:00
Tom Lane eb4f58ad40 Don't try to run clauseless index scans on index types that don't support
it.  Per report from Marinos Yannikos.
2005-04-20 21:48:04 +00:00
Tom Lane a8ac7d8713 Fix mis-display of negative fractional seconds in interval values for
--enable-integer-datetimes case.  Per report from Oliver Siegmar.
2005-04-20 17:14:50 +00:00
Tom Lane 9d64632144 Minor performance improvement: avoid unnecessary creation/unioning of
bitmaps for multiple indexscans.  Instead just let each indexscan add
TIDs directly into the BitmapOr node's result bitmap.
2005-04-20 15:48:36 +00:00
Bruce Momjian de4fbfadc5 Add:
> * Add tool to query pg_stat_* tables and report indexes that aren't needed
>   or tables that might need indexes
2005-04-20 02:48:11 +00:00
Bruce Momjian e5c7c05168 Add:
> * Log queries where the optimizer row estimates were dramatically
>   different from the number of rows actually found (?)
2005-04-20 02:43:49 +00:00
Bruce Momjian 047b8a71d1 Add:
> * All ability to monitor the use of temporary sort files
2005-04-20 01:17:34 +00:00
Tom Lane 4a8c5d0375 Create executor and planner-backend support for decoupled heap and index
scans, using in-memory tuple ID bitmaps as the intermediary.  The planner
frontend (path creation and cost estimation) is not there yet, so none
of this code can be executed.  I have tested it using some hacked planner
code that is far too ugly to see the light of day, however.  Committing
now so that the bulk of the infrastructure changes go in before the tree
drifts under me.
2005-04-19 22:35:18 +00:00
Teodor Sigaev 04ce41ca62 Add comment about permissions on pg_ts* tables 2005-04-19 13:58:48 +00:00
Bruce Momjian fa66de98a9 >>>>Luckily, PG 8 is available for this. Do you have a short example?
>>>
>>>No, and I think it should be in the manual as an example.
>>>
>>>You will need to enter a loop that uses exception handling to detect
>>>unique_violation.
>>
>>Pursuant to an IRC discussion to which Dennis Bjorklund and
>>Christopher Kings-Lynne made most of the contributions, please find
>>enclosed an example patch demonstrating an UPSERT-like capability.
>>

David Fetter
2005-04-19 03:55:43 +00:00
Bruce Momjian bd32a25598 > >Luckily, PG 8 is available for this. Do you have a short example?
>
> No, and I think it should be in the manual as an example.
>
> You will need to enter a loop that uses exception handling to detect
> unique_violation.

Pursuant to an IRC discussion to which Dennis Bjorklund and
Christopher Kings-Lynne made most of the contributions, please find
enclosed an example patch demonstrating an UPSERT-like capability.

David Fetter
2005-04-19 03:37:20 +00:00
Bruce Momjian 7cce39c7ce The following patch should allow UPDATE_INTERVAL to be specified on the
command line. We find this useful because we frequently deal with
thousands of tables in an environment where neither the databases nor
the tables are updated frequently. This helps allow us to cut down on
the overhead of updating the list for every other primary loop of
pg_autovacuum.

I chose -i as the command-line argument and documented it briefly in
the README.

The patch was applied to the 7.4.7 version of pg_autovacuum in contrib.

Thomas F.O'Connell
2005-04-19 03:35:15 +00:00
Bruce Momjian aa8bdab272 Attached patch gets rid of the global timezone in the following steps:
* Changes the APIs to the timezone functions to take a pg_tz pointer as
an argument, representing the timezone to use for the selected
operation.

* Adds a global_timezone variable that represents the current timezone
in the backend as set by SET TIMEZONE (or guc, or env, etc).

* Implements a hash-table cache of loaded tables, so we don't have to
read and parse the TZ file everytime we change a timezone. While not
necesasry now (we don't change timezones very often), I beleive this
will be necessary (or at least good) when "multiple timezones in the
same query" is eventually implemented. And code-wise, this was the time
to do it.


There are no user-visible changes at this time. Implementing the
"multiple zones in one query" is a later step...

This also gets rid of some of the cruft needed to "back out a timezone
change", since we previously couldn't check a timezone unless it was
activated first.

Passes regression tests on win32, linux (slackware 10) and solaris x86.

Magnus Hagander
2005-04-19 03:13:59 +00:00
Bruce Momjian dd39dd232f Update PITR wording, per Simon. 2005-04-19 01:39:50 +00:00
Tom Lane c822fe05ae pg_dumpall should enforce the server version check for itself, rather
than simply passing it down to pg_dump.  Else, version-related failures
in pg_dumpall itself generate unhelpful error messages.
2005-04-18 23:47:52 +00:00
Bruce Momjian 8023b7fa5a Add WAL entry about compression. 2005-04-18 18:30:56 +00:00
Bruce Momjian 07dfdb8dd0 Added to TODO:
> * Compress WAL entries [wal]
2005-04-18 18:29:57 +00:00
Bruce Momjian 01979d1bd5 Update PITR setence to mention WAL and file system dump. 2005-04-18 17:40:40 +00:00
Tom Lane 7aa066f11d record_in and record_recv must be careful to return a separately
pfree'able result, since some callers expect to be able to pfree
the result of a pass-by-reference function.  Per report from Chris Trawick.
2005-04-18 17:11:05 +00:00
Bruce Momjian d304067695 Update PITR TODO items:
<   failure.
>   failure.  This could be triggered by a user command or a timer.
< * Force archiving of partially-full WAL files when pg_stop_backup() is
<   called or the server is stopped
> * Automatically force archiving of partially-filled WAL files when
>   pg_stop_backup() is called or the server is stopped
2005-04-18 15:03:21 +00:00
Bruce Momjian 54fe332776 Update TODO script sample. 2005-04-18 14:44:04 +00:00
Bruce Momjian 03d712d9f4 Update for HTML markup. 2005-04-18 14:42:35 +00:00
Bruce Momjian 68d2f9283d Add description that WAL files used during backup have to be archived
before you are done.
2005-04-18 13:11:04 +00:00
Bruce Momjian c68f6d7963 Add HTML version of TODO to CVS, for web site use. 2005-04-18 12:58:45 +00:00
Bruce Momjian 11ab2b85d7 Add HTML TODO version to CVS. 2005-04-18 12:58:11 +00:00
Bruce Momjian 584693cc6d Add description about partial WAL archiving for PITR:
>
>   Doing this will allow administrators to know more easily when the
>   archive contins all the files needed for point-in-time recovery.
2005-04-18 12:51:41 +00:00
Bruce Momjian 41d64a185e Fix html. 2005-04-18 03:46:31 +00:00
Bruce Momjian f1e8b57731 Test new html tag. 2005-04-18 03:17:23 +00:00
Bruce Momjian c57a418ce6 Add:
> * Force archiving of partially-full WAL files when pg_stop_backup() is
>   called or the server is stopped
2005-04-18 03:00:44 +00:00
Bruce Momjian d755688f24 Update PITR mention of which WAL files are needed. 2005-04-18 01:29:00 +00:00
Tom Lane db30652135 Initial implementation of lossy-tuple-bitmap data structures.
Not connected to anything useful yet ...
2005-04-17 22:24:02 +00:00
Bruce Momjian 18b985055d Clarify name of file to be checked for PITR expiring. 2005-04-17 03:05:19 +00:00
Bruce Momjian 1a6ad669fb Fix comment typo. 2005-04-17 03:04:29 +00:00
Tom Lane d8b1bf4791 Create a new 'MultiExecProcNode' call API for plan nodes that don't
return just a single tuple at a time.  Currently the only such node
type is Hash, but I expect we will soon have indexscans that can return
tuple bitmaps.  A side benefit is that EXPLAIN ANALYZE now shows the
correct tuple count for a Hash node.
2005-04-16 20:07:35 +00:00
Tom Lane 85eee28cec Minor improvements to locale documentation. 2005-04-16 16:50:01 +00:00
Tom Lane 5f0a974ea9 Reduce PANIC to ERROR in several xlog routines that are used in both
critical and noncritical contexts (an example of noncritical being
post-checkpoint removal of dead xlog segments).  In the critical cases
the CRIT_SECTION mechanism will cause ERROR to be promoted to PANIC
anyway, and in the noncritical cases we shouldn't let an error take
down the entire database.  Arguably there should be *no* explicit
PANIC errors in this module, only more START/END_CRIT_SECTION calls,
but I didn't go that far.  (Yet.)
2005-04-15 22:19:48 +00:00