pdf viewer in asp net c# : Add signature image to pdf acrobat Library SDK API .net asp.net wpf sharepoint postgresql-9.4-A445-part2967

Chapter 13. Concurrency Control
SHARE
Conflicts with the
ROW EXCLUSIVE
,
SHARE UPDATE EXCLUSIVE
,
SHARE ROW EXCLUSIVE
,
EXCLUSIVE
,and
ACCESS EXCLUSIVE
lock modes. This mode protects a table against concur-
rent data changes.
Acquired by
CREATE INDEX
(without
CONCURRENTLY
).
SHARE ROW EXCLUSIVE
Conflicts with the
ROW EXCLUSIVE
,
SHARE UPDATE EXCLUSIVE
,
SHARE
,
SHARE ROW
EXCLUSIVE
,
EXCLUSIVE
,and
ACCESS EXCLUSIVE
lock modes. This mode protects a table
against concurrent data changes, and is self-exclusive so that only one session can hold it at a
time.
This lock mode is not automatically acquired by any PostgreSQL command.
EXCLUSIVE
Conflicts withthe
ROW SHARE
,
ROW EXCLUSIVE
,
SHARE UPDATE EXCLUSIVE
,
SHARE
,
SHARE
ROW EXCLUSIVE
,
EXCLUSIVE
,and
ACCESS EXCLUSIVE
lock modes. This mode allows only
concurrent
ACCESS SHARE
locks, i.e., only reads from the table can proceed in parallel with a
transaction holdingthis lock mode.
Acquired by
REFRESH MATERIALIZED VIEW CONCURRENTLY
.
ACCESS EXCLUSIVE
Conflicts with locks of all modes (
ACCESS SHARE
,
ROW SHARE
,
ROW EXCLUSIVE
,
SHARE
UPDATE EXCLUSIVE
,
SHARE
,
SHARE ROW EXCLUSIVE
,
EXCLUSIVE
, and
ACCESS
EXCLUSIVE
). This mode guarantees that the holder is the only transaction accessing the table in
any way.
Acquired by the
DROP TABLE
,
TRUNCATE
,
REINDEX
,
CLUSTER
,
VACUUM FULL
,and
REFRESH
MATERIALIZED VIEW
(without
CONCURRENTLY
)commands. Many forms of
ALTER TABLE
also acquire a lock at this level (see ALTER TABLE). This is also the default lock mode for
LOCK TABLE
statements that do not specify a mode explicitly.
Tip: Only an
ACCESS EXCLUSIVE
lock blocks a
SELECT
(without
FOR UPDATE/SHARE
)statement.
Once acquired, a lock is normally heldtill end of transaction. But if a lock is acquired after establish-
ing a savepoint, the lock is released immediately if the savepoint is rolled back to. This is consistent
with the principle that
ROLLBACK
cancels all effects of the commands since the savepoint. The same
holds for locks acquired withina PL/pgSQL exception block:an error escape from the block releases
locks acquired within it.
Table 13-2. Conflicting Lock Modes
Requested
Lock
Mode
Current Lock Mode
ACCESS
SHARE
ROW
SHARE
ROW
EXCLU-
SIVE
SHARE
UP-
DATE
EXCLU-
SIVE
SHARE
SHARE
ROW
EXCLU-
SIVE
EXCLUSIVE
ACCESS
EXCLU-
SIVE
378
Add signature image to pdf acrobat - insert images into PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sample C# code to add image, picture, logo or digital photo into PDF document page using PDF page editor control
add photo to pdf preview; add png to pdf preview
Add signature image to pdf acrobat - VB.NET PDF insert image library: insert images into PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide VB.NET Programmers How to Add Images in PDF Document
adding a jpg to a pdf; adding images to pdf
Chapter 13. Concurrency Control
Requested
Lock
Mode
Current Lock Mode
ACCESS
SHARE
ROW
SHARE
ROW
EXCLU-
SIVE
SHARE
UP-
DATE
EXCLU-
SIVE
SHARE
SHARE
ROW
EXCLU-
SIVE
EXCLUSIVE
ACCESS
EXCLU-
SIVE
ACCESS
SHARE
X
ROW
SHARE
X
X
ROW
EXCLU-
SIVE
X
X
X
X
SHARE
UPDATE
EXCLU-
SIVE
X
X
X
X
X
SHARE
X
X
X
X
X
SHARE
ROW
EXCLU-
SIVE
X
X
X
X
X
X
EXCLUSIVE
X
X
X
X
X
X
X
ACCESS
EXCLU-
SIVE
X
X
X
X
X
X
X
X
13.3.2. Row-level Locks
In addition to table-level locks, there are row-level locks, which are listed as below with the contexts
in which they are used automaticallybyPostgreSQL. SeeTable13-3 for a completetable of row-level
lock conflicts. Note that a transaction can hold conflicting locks on the same row, even in different
subtransactions; butother than that, twotransactions can never hold conflictinglocks onthesamerow.
Row-level locks do not affect data querying; they block only writers and lockers to the same row.
Row-level Lock Modes
FOR UPDATE
FOR UPDATE
causes the rows retrieved by the
SELECT
statement to be locked as though for
update. This prevents them from being locked, modified or deleted by other transactions until
the current transaction ends. That is, other transactions that attempt
UPDATE
,
DELETE
,
SELECT
FOR UPDATE
,
SELECT FOR NO KEY UPDATE
,
SELECT FOR SHARE
or
SELECT FOR KEY
379
.NET PDF Document Viewing, Annotation, Conversion & Processing
Convert image files to PDF. File & Page Process. Allow to create digital signature. Easy to set PDF file permission. Add, insert PDF native annotations to PDF file
how to add image to pdf in preview; how to add photo to pdf in preview
BMP to PDF Converter | Convert Bitmap to PDF, Convert PDF to BMP
Also designed to be used add-on for .NET Image SDK, RasterEdge Bitmap to PDF Converter can Powerful image converter for Bitmap and PDF files; No need for
add an image to a pdf with acrobat; add photo to pdf online
Chapter 13. Concurrency Control
SHARE
of these rows will be blocked until the current transaction ends; conversely,
SELECT
FOR UPDATE
will wait for a concurrent transaction that has run any of those commands on the
same row, and will then lock and return the updated row (or no row, if the row was deleted).
Within a
REPEATABLE READ
or
SERIALIZABLE
transaction, however, an error will be thrown
if a row to be locked has changed since the transaction started. For further discussion see
Section 13.4.
The
FOR UPDATE
lock mode is also acquired by any
DELETE
on a row, and also by an
UPDATE
that modifies the values on certain columns. Currently, the set of columns considered for the
UPDATE
case are those that have a unique index on them that can be used in a foreign key (so
partial indexes and expressional indexes are not considered), but this may change in the future.
FOR NO KEY UPDATE
Behaves similarly to
FOR UPDATE
,except that the lock acquired is weaker: this lock will not
block
SELECT FOR KEY SHARE
commands that attempt to acquire a lock on the same rows.
This lock mode is also acquired by any
UPDATE
that does not acquire a
FOR UPDATE
lock.
FOR SHARE
Behaves similarly to
FOR NO KEY UPDATE
,except that it acquires a shared lock rather than
exclusive lock on each retrieved row. A shared lock blocks other transactions from performing
UPDATE
,
DELETE
,
SELECT FOR UPDATE
or
SELECT FOR NO KEY UPDATE
on these rows, but
it does not prevent them from performing
SELECT FOR SHARE
or
SELECT FOR KEY SHARE
.
FOR KEY SHARE
Behaves similarly to
FOR SHARE
, except that the lock is weaker:
SELECT FOR UPDATE
is
blocked, but not
SELECT FOR NO KEY UPDATE
.A key-shared lock blocks other transactions
from performing
DELETE
or any
UPDATE
that changes the keyvalues, but not other
UPDATE
,and
neither does it prevent
SELECT FOR NO KEY UPDATE
,
SELECT FOR SHARE
,or
SELECT FOR
KEY SHARE
.
PostgreSQL doesn’t remember any information about modified rows in memory, so there is no limit
on the number of rows locked at one time. However, locking a row might cause a disk write, e.g.,
SELECT FOR UPDATE
modifies selected rows to mark them locked, and so will result in disk writes.
Table 13-3. Conflicting Row-level Locks
Requested
Lock Mode
Current Lock Mode
FOR KEY
SHARE
FOR SHARE
FOR NO KEY
UPDATE
FOR UPDATE
FOR KEY
SHARE
X
FOR SHARE
X
X
FOR NO KEY
UPDATE
X
X
X
FOR UPDATE
X
X
X
X
13.3.3. Page-level Locks
In addition to table and row locks, page-level share/exclusive locks are used to control read/write
access to table pages in the shared buffer pool. These locks are released immediately after a row is
380
JPEG to PDF Converter | Convert JPEG to PDF, Convert PDF to JPEG
It can be used standalone. JPEG to PDF Converter is able to convert image files to PDF directly without the software Adobe Acrobat Reader for conversion.
acrobat insert image into pdf; acrobat insert image in pdf
PDF to WORD Converter | Convert PDF to Word, Convert Word to PDF
out transformation between different kinds of image files and Word Converter has accurate output, and PDF to Word need the support of Adobe Acrobat & Microsoft
how to add an image to a pdf in reader; adding images to pdf files
Chapter 13. Concurrency Control
fetched or updated. Application developers normally need not be concerned with page-level locks,
but they are mentioned here for completeness.
13.3.4. Deadlocks
The use of explicit locking can increase the likelihood of deadlocks, wherein two (or more) transac-
tions each hold locks that the other wants. For example, if transaction 1 acquires an exclusive lock
on table A and then tries to acquire an exclusive lock on table B, while transaction 2 has already
exclusive-locked table B and now wants an exclusive lock on table A, then neither one can proceed.
PostgreSQL automatically detects deadlock situations and resolves them by abortingoneof the trans-
actions involved, allowing the other(s) to complete. (Exactly which transaction will be aborted is
difficult to predict and should not be relied upon.)
Note that deadlocks can also occur as the result of row-level locks (and thus, they can occur even if
explicit locking is not used). Consider the case in which two concurrent transactions modify a table.
The first transaction executes:
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;
This acquires a row-level lock on the row with the specified account number. Then, the second trans-
action executes:
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;
The first
UPDATE
statement successfully acquires a row-level lock on the specified row, soit succeeds
in updating that row. However, the second
UPDATE
statement finds that the row it is attempting to
update has already been locked, so it waits for the transaction that acquired the lock to complete.
Transaction two is now waiting on transaction one to complete before it continues execution. Now,
transaction one executes:
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
Transaction one attempts to acquire a row-level lock on the specified row, but it cannot: transaction
two already holds such a lock. So it waits for transaction two to complete. Thus, transaction one is
blocked on transaction two, and transaction two is blocked on transaction one: a deadlock condition.
PostgreSQL will detect this situation and abort one of the transactions.
The best defense against deadlocks is generally to avoid them by being certain that all applications
usinga database acquire locks onmultiple objects in a consistent order. In the example above, if both
transactions had updated the rows in the same order, no deadlock would have occurred. One should
also ensure that the first lock acquired on an object in a transaction is the most restrictive mode that
will be needed for that object. If it is not feasible to verify this in advance, then deadlocks can be
handled on-the-flyby retryingtransactions that abort due to deadlocks.
Solongas nodeadlock situationis detected, a transaction seekingeither atable-level or row-levellock
will wait indefinitely for conflicting locks to be released. This means it is a bad idea for applications
to hold transactions open for long periods of time (e.g., while waiting for user input).
13.3.5. Advisory Locks
PostgreSQL provides a means for creating locks that have application-defined meanings. These are
called advisory locks, because the system does not enforce their use — it is up to the application to
381
GIF to PDF Converter | Convert GIF to PDF, Convert PDF to GIF
use of external applications & Adobe Acrobat Reader. This GIF to PDF Converter provided by RasterEdge is Features and Benefits. Powerful image converter for GIF
add picture to pdf preview; how to add an image to a pdf file
DICOM to PDF Converter | Convert DICOM to PDF, Convert PDF to
Different from other image converters, users do not need to load Adobe Acrobat or any other print drivers when they use DICOM to PDF Converter.
add a jpg to a pdf; add jpg to pdf preview
Chapter 13. Concurrency Control
use them correctly. Advisory locks can be useful for locking strategies that are an awkward fit for
the MVCC model. For example, a common use of advisory locks is to emulate pessimistic locking
strategies typical of so-called “flat file” data management systems. While a flag stored in a table
could be used for the same purpose, advisory locks are faster, avoid table bloat, andare automatically
cleaned up bythe server at the end of the session.
There are two ways to acquire an advisory lock in PostgreSQL: at session level or at transaction
level. Once acquired at session level, an advisory lock is held until explicitly released or the session
ends. Unlike standard lock requests, session-level advisory lock requests do not honor transaction
semantics: a lock acquired during a transaction that is later rolled back will still be held following
the rollback, and likewise an unlock is effective even if the calling transaction fails later. A lock can
be acquired multiple times by its owning process; for each completed lock request there must be a
corresponding unlock request before the lock is actually released. Transaction-level lock requests, on
the other hand, behave more like regular lock requests: they are automatically released at the end of
the transaction, and there is no explicit unlock operation. This behavior is often more convenient than
the session-level behavior for short-term usage of an advisory lock. Session-level and transaction-
level lock requests for the same advisory lock identifier will block each other in the expected way. If
asession already holds a given advisory lock, additional requests by it will always succeed, even if
other sessions are awaiting the lock; this statement is true regardless of whether the existing lockhold
and new request are at session level or transactionlevel.
Like all locks in PostgreSQL, a complete list of advisory locks currently held by any session can be
found in the
pg_locks
system view.
Both advisory locks and regular locks are stored in a shared memory pool whose size is defined by
the configuration variables max_locks_per_transactionand max_connections. Care must betaken not
to exhaust this memory or the server will be unable to grant any locks at all. This imposes an upper
limit on the number of advisory locks grantable by the server, typically in the tens to hundreds of
thousands depending on how the server is configured.
In certain cases using advisory lockingmethods, especially in queries involving explicit ordering and
LIMIT
clauses, care must be taken to control the locks acquired because of the order in which SQL
expressions are evaluated. For example:
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger!
SELECT pg_advisory_lock(q.id) FROM
(
SELECT id FROM foo WHERE id > 12345 LIMIT 100
) q; -- ok
In the above queries, the secondform is dangerous because the
LIMIT
is not guaranteed tobe applied
before the locking function is executed. This might cause some locks to be acquired that the applica-
tion was not expecting, and hence would fail to release (until it ends the session). From the point of
view of the application, suchlocks would be dangling, although still viewable in
pg_locks
.
The functions providedto manipulate advisory locks are described in Section 9.26.9.
13.4. Data Consistency Checks at the Application Level
Itis verydifficultto enforcebusinessrules regardingdata integrityusingReadCommitted transactions
because the view of the data is shifting with each statement, and even a single statement may not
restrict itself to the statement’s snapshot if a write conflict occurs.
382
TIFF to PDF Converter | Convert TIFF to PDF, Convert PDF to TIFF
PDF to TIFF Converter doesn't require other third-party such as Adobe Acrobat. PDF to TIFF Converter can create the output TIFF image with 68-1024 dpi.
add image to pdf online; adding image to pdf
Chapter 13. Concurrency Control
While a Repeatable Read transaction has a stable view of the data throughout its execution, there is
asubtle issue with using MVCC snapshots for data consistency checks, involving something known
as read/write conflicts. If one transaction writes data and a concurrent transaction attempts to read
the same data (whether before or after the write), it cannot see the work of the other transaction. The
reader then appears to have executed first regardless of which started first or which committed first.
If that is as far as it goes, there is no problem, but if the reader also writes data which is read by a
concurrenttransaction there is now a transactionwhich appears to have run before either of the previ-
ouslymentionedtransactions. If the transaction whichappears tohave executed last actuallycommits
first, it is very easy for a cycle toappear ina graphof the order of executionof the transactions. When
such a cycle appears, integrity checks will not work correctly without some help.
As mentioned inSection 13.2.3, Serializable transactions are justRepeatable Readtransactions which
add nonblocking monitoring for dangerous patterns of read/write conflicts. Whena pattern is detected
which couldcause acycle intheapparent order of execution, one of the transactions involvedis rolled
back to break the cycle.
13.4.1. Enforcing Consistency With Serializable
Transactions
If the Serializable transaction isolation level is used for all writes and for all reads which need a
consistent view of the data, no other effort is required to ensure consistency. Software from other en-
vironments which is written to use serializable transactions to ensure consistency should “just work”
in this regard in PostgreSQL.
When using this technique, it will avoid creating an unnecessary burden for application
programmers if the application software goes through a framework which automatically retries
transactions which are rolled back with a serialization failure. It may be a good idea to set
default_transaction_isolation
to
serializable
.It would also be wise to take some action
to ensure that no other transaction isolation level is used, either inadvertently or to subvert integrity
checks, through checks of the transaction isolation level in triggers.
See Section 13.2.3 for performance suggestions.
Warning
This level of integrity protection using Serializable transactions does not yet
extend to hot standby mode (Section 25.5). Because of that, those using hot
standby may want to use Repeatable Read and explicit locking on the master.
13.4.2. Enforcing Consistency With Explicit Blocking Locks
When non-serializable writes are possible, to ensure the current validity of a row and protect it
against concurrent updates one must use
SELECT FOR UPDATE
,
SELECT FOR SHARE
,or an appro-
priate
LOCK TABLE
statement. (
SELECT FOR UPDATE
and
SELECT FOR SHARE
lock just the re-
turned rows against concurrent updates, while
LOCK TABLE
locks the whole table.) This should be
taken into account when porting applications to PostgreSQL from other environments.
Also of note to those converting from other environments is the fact that
SELECT FOR UPDATE
does not ensure that a concurrent transaction will not update or delete a selected row. To do that
in PostgreSQL you must actually update the row, evenif no values need to be changed.
SELECT FOR
UPDATE
temporarily blocks other transactions from acquiring the same lock or executing an
UPDATE
or
DELETE
which would affect the locked row, but once the transaction holding this lock commits or
383
Chapter 13. Concurrency Control
rolls back, a blocked transaction will proceed with the conflicting operation unless an actual
UPDATE
of the row was performedwhile the lock was held.
Global validity checks require extra thought under non-serializable MVCC. For example, a banking
application might wish to check that the sum of all credits in one table equals the sum of debits in
another table, when both tables are being actively updated. Comparing the results of two successive
SELECT sum(...)
commands will not work reliably in Read Committed mode, since the second
query will likely include the results of transactions not counted by the first. Doing the two sums in
asingle repeatable read transaction will give an accurate picture of only the effects of transactions
that committed before the repeatable read transaction started — but one might legitimately wonder
whether the answer is still relevant by the time it is delivered. If the repeatable read transaction it-
self applied some changes before trying to make the consistency check, the usefulness of the check
becomes even more debatable, since now it includes some but not all post-transaction-start changes.
In such cases a careful person might wish to lock all tables needed for the check, in order to get an
indisputable picture of current reality. A
SHARE
mode (or higher) lock guarantees that there are no
uncommitted changes in the locked table, other than those of the current transaction.
Note also that if one is relying on explicit locking to prevent concurrent changes, one should either
use Read Committed mode, or in Repeatable Read mode be careful to obtain locks before perform-
ing queries. A lock obtained by a repeatable read transaction guarantees that no other transactions
modifying the table are still running, butif the snapshot seen by the transactionpredates obtaining the
lock, it mightpredate some now-committed changes inthe table. Arepeatable readtransaction’s snap-
shot is actually frozen at the start of its first query or data-modification command (
SELECT
,
INSERT
,
UPDATE
,or
DELETE
), so it is possible to obtain locks explicitly before the snapshot is frozen.
13.5. Caveats
Some DDL commands, currently only TRUNCATE and the table-rewriting forms of ALTER TA-
BLE, are not MVCC-safe. This means that after the truncation or rewrite commits, the table will
appear empty to concurrent transactions, if theyare using a snapshot taken before the DDL command
committed. This will only be an issue for a transaction that did not access the table in question be-
fore the DDL command started — any transaction that has done so would hold at least an
ACCESS
SHARE
table lock, which would block the DDL command until that transaction completes. So these
commands will not cause any apparent inconsistency in the table contents for successive queries on
the target table, butthey couldcause visible inconsistencybetween the contents of the target table and
other tables in the database.
Support for the Serializable transaction isolation level has not yet been added to Hot Standby replica-
tion targets (describedin Section 25.5). The strictestisolation levelcurrentlysupported in hot standby
mode is Repeatable Read. While performing all permanent database writes within Serializable trans-
actions on themaster willensurethat all standbys willeventually reachaconsistentstate, aRepeatable
Read transaction run on the standby can sometimes see a transient state that is inconsistent with any
serial execution of the transactions on the master.
13.6. Locking and Indexes
Though PostgreSQL provides nonblockingread/write access to table data, nonblockingread/write ac-
cess is not currently offered for every index access method implemented in PostgreSQL. The various
384
Chapter 13. Concurrency Control
index types are handled as follows:
B-tree, GiST and SP-GiST indexes
Short-term share/exclusive page-level locks are used for read/write access. Locks are released
immediately after each index row is fetched or inserted. These index types provide the highest
concurrency without deadlock conditions.
Hash indexes
Share/exclusive hash-bucket-level locks are used for read/write access. Locks are released after
the whole bucket is processed. Bucket-level locks provide better concurrency than index-level
ones, but deadlock is possible since the locks are held longer than one index operation.
GIN indexes
Short-term share/exclusive page-level locks are used for read/write access. Locks are released
immediatelyafter each indexrow is fetched or inserted. Butnote that insertionof aGIN-indexed
value usually produces several index key insertions per row, so GIN might do substantial work
for a single value’s insertion.
Currently, B-tree indexes offer the best performance for concurrent applications; since they alsohave
more features than hash indexes, they are the recommended index type for concurrent applications
that need to index scalar data. When dealing with non-scalar data, B-trees are not useful, and GiST,
SP-GiST or GIN indexes should be used instead.
385
Chapter 14. Performance Tips
Queryperformancecanbe affected by many things. Someof these canbecontrolledbythe user, while
others are fundamental totheunderlying designof the system. This chapter provides some hints about
understanding andtuning PostgreSQL performance.
14.1. Using
EXPLAIN
PostgreSQL devisesa query planfor eachquery it receives. Choosingthe right plantomatchthe query
structure and the properties of the data is absolutely critical for good performance, so the system
includes a complex planner that tries to choose good plans. You can use the EXPLAIN command
to see what query plan the planner creates for any query. Plan-reading is an art that requires some
experience to master, but this section attempts to cover the basics.
Examples in this section are drawnfrom the regression test database after doinga
VACUUM ANALYZE
,
using 9.3 development sources. You should be able to get similar results if you try the examples
yourself, but your estimated costs and row counts might vary slightly because
ANALYZE
’s statistics
arerandom samples rather thanexact, and becausecostsareinherentlysomewhatplatform-dependent.
The examples use
EXPLAIN
’s default “text” output format, which is compact and convenient for
humans to read. If you want to feed
EXPLAIN
’s output to a program for further analysis, you should
use one of its machine-readable output formats (XML, JSON, or YAML) instead.
14.1.1.
EXPLAIN
Basics
The structure of a query plan is a tree of plan nodes. Nodes at the bottom level of the tree are scan
nodes: they return raw rows from a table. There are different types of scan nodes for different table
access methods: sequential scans, index scans, and bitmap index scans. There are also non-table row
sources, such as
VALUES
clauses and set-returning functions in
FROM
, which have their own scan
node types. If the query requires joining, aggregation, sorting, or other operations on the raw rows,
then there will be additional nodes above the scan nodes to perform these operations. Again, there is
usually more than one possible way to do these operations, so different node types can appear here
too. The output of
EXPLAIN
has one line for each node in the plan tree, showing the basic node type
plus the cost estimates that the planner made for the execution of that plan node. Additional lines
might appear, indented from the node’s summary line, to show additional properties of the node. The
very first line (the summary line for the topmost node) has the estimated total execution cost for the
plan; it is this number that the planner seeks to minimize.
Here is a trivial example, just to show what the output looks like:
EXPLAIN SELECT
*
FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1
(cost=0.00..458.00 rows=10000 width=244)
Since this query has no
WHERE
clause, it must scan all the rows of the table, so the planner has chosen
to use a simple sequential scan plan. The numbers that are quoted in parentheses are (left to right):
386
Chapter 14. Performance Tips
Estimated start-up cost. This is the time expended before the output phase can begin, e.g., time to
do the sorting in a sort node.
Estimated total cost. This is stated on the assumption that the plan node is run to completion, i.e.,
all available rows are retrieved. In practice a node’s parent node might stop short of reading all
available rows (see the
LIMIT
example below).
Estimated number of rows output by this plan node. Again, the node is assumed to be run to
completion.
Estimated average width of rows output by this plan node (in bytes).
The costs are measured in arbitrary units determined by the planner’s cost parameters (see Section
18.7.2). Traditionalpractice istomeasurethecostsinunits of diskpagefetches;that is, seq_page_cost
is conventionally set to
1.0
and the other cost parameters are set relative tothat. The examples in this
section are run with the default cost parameters.
It’s important to understand that the cost of an upper-level node includes the cost of all its child
nodes. It’s also important to realize that the cost only reflects things that the planner cares about. In
particular, the cost does not consider the time spent transmitting result rows to the client, which could
be an important factor in the real elapsed time; but the planner ignores it because it cannot change it
by altering the plan. (Every correct plan will output the same row set, we trust.)
The
rows
value is a little tricky because it is not the number of rows processed or scanned by the
plan node, but rather the number emitted by the node. This is often less than the number scanned,
as a result of filtering by any
WHERE
-clause conditions that are being applied at the node. Ideally the
top-level rows estimate will approximate the number of rows actually returned, updated, or deleted
by the query.
Returning to our example:
EXPLAIN SELECT
*
FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1
(cost=0.00..458.00 rows=10000 width=244)
These numbers are derived very straightforwardly. If you do:
SELECT relpages, reltuples FROM pg_class WHERE relname = ’tenk1’;
youwill find that
tenk1
has 358 disk pages and 10000 rows. The estimatedcost is computedas (disk
pages read * seq_page_cost) + (rows scanned * cpu_tuple_cost). By default,
seq_page_cost
is 1.0
and
cpu_tuple_cost
is 0.01, so the estimated cost is (358 * 1.0) + (10000 * 0.01) = 458.
Now let’s modify the queryto add a
WHERE
condition:
EXPLAIN SELECT
*
FROM tenk1 WHERE unique1 < 7000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on tenk1
(cost=0.00..483.00 rows=7001 width=244)
Filter: (unique1 < 7000)
Notice that the
EXPLAIN
output shows the
WHERE
clause being applied as a “filter” condition attached
to the Seq Scan plan node. This means that the plan node checks the condition for each row it scans,
387
Documents you may be interested
Documents you may be interested