pdf viewer in asp net c# : How to add image to pdf reader SDK control service wpf web page azure dnn postgresql-9.4-A440-part2962

Chapter 11. Indexes
11.8. Partial Indexes
Apartialindex is an index builtover a subset of a table; the subset is defined bya conditional expres-
sion (called the predicate of the partial index). The index contains entries only for those table rows
that satisfy the predicate. Partial indexes are a specialized feature, but there are several situations in
which they are useful.
One major reasonfor using a partial indexis to avoid indexing common values. Since a query search-
ing for a common value (one that accounts for more than a few percent of all the table rows) will not
use the index anyway, there is no point in keepingthose rows in the index at all. This reduces the size
of the index, which willspeed upthose queries that do use the index. It will also speed up many table
update operations because the index does not need to be updated in all cases. Example 11-1 shows a
possible application of this idea.
Example 11-1. Setting up a Partial Index to Exclude Common Values
Suppose you are storing web server access logs in a database. Most accesses originate from the IP
address range of your organization but some are from elsewhere (say, employees on dial-up connec-
tions). If your searches by IP are primarily for outside accesses, you probably do not need to index
the IP range that corresponds to your organization’s subnet.
Assume a table like this:
CREATE TABLE access_log (
url varchar,
client_ip inet,
...
);
To create a partial index that suits our example, use a command such as this:
CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
WHERE NOT (client_ip > inet ’192.168.100.0’ AND
client_ip < inet ’192.168.100.255’);
Atypical query that can use this index would be:
SELECT
*
FROM access_log
WHERE url = ’/index.html’ AND client_ip = inet ’212.78.10.32’;
Aquery that cannot use this index is:
SELECT
*
FROM access_log
WHERE client_ip = inet ’192.168.100.23’;
Observe that this kind of partial index requires that the common values be predetermined, so such
partial indexes are best used for data distributions that do not change. The indexes can be recreated
occasionally to adjust for new data distributions, but this adds maintenance effort.
Another possible use for a partial index is to exclude values from the index that the typical query
workload is not interested in; this is shown in Example 11-2. This results in the same advantages as
listed above, but it prevents the “uninteresting” values from being accessed via that index, even if
an index scan might be profitable in that case. Obviously, setting up partial indexes for this kind of
scenario will require a lot of care and experimentation.
328
How to add image to pdf reader - 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
adding an image to a pdf in preview; adding an image to a pdf file
How to add image to pdf reader - 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
add an image to a pdf acrobat; add picture to pdf file
Chapter 11. Indexes
Example 11-2. Setting up a Partial Index to Exclude Uninteresting Values
If you have a table that contains both billed and unbilled orders, where the unbilled orders take up a
small fraction of the total table and yet those are the most-accessed rows, you can improve perfor-
mance by creating an index on just the unbilled rows. The command to create the index would look
like this:
CREATE INDEX orders_unbilled_index ON orders (order_nr)
WHERE billed is not true;
Apossible query to use this index would be:
SELECT
*
FROM orders WHERE billed is not true AND order_nr < 10000;
However, the index can also be used in queries that do not involve
order_nr
at all, e.g.:
SELECT
*
FROM orders WHERE billed is not true AND amount > 5000.00;
This is not as efficient as apartialindex on the
amount
column would be, since the system has toscan
the entire index. Yet, if there are relatively few unbilled orders, using this partial index justto find the
unbilled orders could be a win.
Note that this query cannot use this index:
SELECT
*
FROM orders WHERE order_nr = 3501;
The order 3501 might be among the billed or unbilled orders.
Example 11-2 also illustrates that the indexed column and the column used in the predicate do not
needtomatch. PostgreSQL supports partialindexes witharbitrarypredicates, solong as onlycolumns
of the table being indexed are involved. However, keep in mind that the predicate must match the
conditions used in the queries that are supposed to benefit from the index. To be precise, a partial
index can be used in a query only if the system can recognize that the
WHERE
condition of the query
mathematicallyimplies the predicate of the index. PostgreSQL does nothave a sophisticated theorem
prover that can recognize mathematically equivalent expressions that are written in different forms.
(Not only is such a general theorem prover extremely difficult to create, it would probably be too
slow to be of any real use.) The system can recognize simple inequality implications, for example
“x < 1” implies “x < 2”; otherwise the predicate condition must exactly match part of the query’s
WHERE
conditionor the index willnot berecognizedas usable. Matching takes placeat query planning
time, not at run time. As a result, parameterized query clauses do not work with a partial index. For
example a prepared query with a parameter might specify “x < ?” whichwill never imply “x < 2” for
all possible values of the parameter.
Athird possible usefor partial indexes does not require the index tobe usedin queries at all. The idea
here is to create a unique index over a subsetof a table, as inExample 11-3. This enforces uniqueness
among the rows that satisfythe index predicate, without constraining those that do not.
Example 11-3. Setting up a Partial Unique Index
Suppose that we have a table describing test outcomes. We wish to ensure that there is only one
“successful” entry for a given subject and target combination, but there might be any number of
“unsuccessful” entries. Here is one way to do it:
CREATE TABLE tests (
subject text,
target text,
success boolean,
...
);
329
C# Imaging - Scan Barcode Image in C#.NET
RasterEdge Barcode Reader DLL add-in enables developers to add barcode image recognition & types, such as Code 128, EAN-13, QR Code, PDF-417, etc.
add picture pdf; pdf insert image
XImage.Barcode Scanner for .NET, Read, Scan and Recognize barcode
VB.NET Write: Add Image to PDF; VB.NET Protect: Add Password to VB.NET Annotate: PDF Markup & Drawing. XDoc.Word for C#; XDoc.Excel for C#; XDoc.PowerPoint for
how to add a photo to a pdf document; acrobat add image to pdf
Chapter 11. Indexes
CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
WHERE success;
This is a particularly efficient approach when there are few successful tests and many unsuccessful
ones.
Finally, a partial index can also be used to override the system’s query plan choices. Also, data sets
with peculiar distributions might cause the system to use an index when it really should not. In that
case the index can be set up so that it is not available for the offending query. Normally, PostgreSQL
makes reasonable choices about index usage (e.g., it avoids them when retrieving common values, so
the earlier example really only saves index size, it is not required to avoid index usage), and grossly
incorrect plan choices are cause for a bug report.
Keep in mind that setting up a partial index indicates that you know at least as much as the query
planner knows, in particular you know when an index might be profitable. Forming this knowledge
requires experienceand understanding of howindexes in PostgreSQL work. In most cases, the advan-
tage of a partial index over a regular indexwill be minimal.
More information about partial indexes can befoundin The casefor partial indexes , Partial indexing
in POSTGRES: research project, and Generalized Partial Indexes (cached version) .
11.9. Operator Classes and Operator Families
An index definition can specify an operator class for each column of an index.
CREATE INDEX
name
ON
table
(
column opclass
[
sort options
] [, ...]);
The operator class identifies the operators to be used by the index for that column. For example, a B-
tree index on the type
int4
would use the
int4_ops
class; this operator class includes comparison
functions for values of type
int4
.In practice the default operator class for the column’s data type
is usually sufficient. The main reason for having operator classes is that for some data types, there
could be more than one meaningful index behavior. For example, we might want to sort a complex-
number data type either by absolute value or by real part. We could do this by defining two operator
classes for the data type andthenselecting the proper class when making an index. The operator class
determines the basic sort ordering (which can then be modified by adding sort options
COLLATE
,
ASC
/
DESC
and/or
NULLS FIRST
/
NULLS LAST
).
There are also some built-inoperator classes besides the default ones:
The
operator
classes
text_pattern_ops
,
varchar_pattern_ops
,
and
bpchar_pattern_ops
support B-tree indexes on the types
text
,
varchar
, and
char
respectively. The difference from the default operator classes is that the values are compared
strictly character by character rather than according to the locale-specific collation rules. This
makes these operator classes suitable for use by queries involving pattern matching expressions
(
LIKE
or POSIX regular expressions) when the database does not use the standard “C” locale. As
an example, you might index a
varchar
column like this:
CREATE INDEX test_index ON test_table (col varchar_pattern_ops);
Note that you should also create an index with the default operator class if you want queries
involving ordinary
<
,
<=
,
>
,or
>=
comparisons to use an index. Such queries cannot use the
xxx
_pattern_ops
operator classes. (Ordinary equality comparisons can use these operator
classes, however.) It is possible to create multiple indexes on the same column with different
operator classes. If you do use the C locale, you do not need the
xxx
_pattern_ops
operator
330
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
Get image information, such as its location, zonal information, metadata, and so on. Able to edit, add, delete, move, and output PDF document image.
add picture to pdf preview; add signature image to pdf acrobat
VB.NET PDF Password Library: add, remove, edit PDF file password
VB: Add Password to PDF with Permission Settings Applied. This VB.NET example shows how to add PDF file password with access permission setting.
add picture to pdf; add image pdf document
Chapter 11. Indexes
classes, because an index with the default operator class is usable for pattern-matching queries in
the C locale.
The following query shows all defined operator classes:
SELECT am.amname AS index_method,
opc.opcname AS opclass_name,
opc.opcintype::regtype AS indexed_type,
opc.opcdefault AS is_default
FROM pg_am am, pg_opclass opc
WHERE opc.opcmethod = am.oid
ORDER BY index_method, opclass_name;
Anoperator class is actuallyjust asubsetof alarger structure calledanoperator family. Incases where
several data types have similar behaviors, it is frequently useful to define cross-data-type operators
and allow these to work with indexes. To do this, the operator classes for each of the types must be
grouped into the same operator family. The cross-type operators are members of the family, but are
not associated with any single class within the family.
This expanded version of the previous query shows the operator family each operator class belongs
to:
SELECT am.amname AS index_method,
opc.opcname AS opclass_name,
opf.opfname AS opfamily_name,
opc.opcintype::regtype AS indexed_type,
opc.opcdefault AS is_default
FROM pg_am am, pg_opclass opc, pg_opfamily opf
WHERE opc.opcmethod = am.oid AND
opc.opcfamily = opf.oid
ORDER BY index_method, opclass_name;
This query shows all defined operator families and all the operators included in eachfamily:
SELECT am.amname AS index_method,
opf.opfname AS opfamily_name,
amop.amopopr::regoperator AS opfamily_operator
FROM pg_am am, pg_opfamily opf, pg_amop amop
WHERE opf.opfmethod = am.oid AND
amop.amopfamily = opf.oid
ORDER BY index_method, opfamily_name, opfamily_operator;
11.10. Indexes and Collations
An index can support only one collation per index column. If multiple collations are of interest,
multiple indexes may be needed.
Consider these statements:
CREATE TABLE test1c (
331
VB.NET PDF Image Extract Library: Select, copy, paste PDF images
DLLs for PDF Image Extraction in VB.NET. In order to run the sample code, the following steps would be necessary. Add necessary references:
add picture to pdf form; how to add an image to a pdf in preview
C# PDF Password Library: add, remove, edit PDF file password in C#
C# Sample Code: Add Password to PDF with Permission Settings Applied in C#.NET. This example shows how to add PDF file password with access permission setting.
add picture to pdf reader; add image to pdf reader
Chapter 11. Indexes
id integer,
content varchar COLLATE "x"
);
CREATE INDEX test1c_content_index ON test1c (content);
The index automatically uses the collation of the underlying column. So a query of the form
SELECT
*
FROM test1c WHERE content >
constant
;
could use the index, because thecomparisonwill bydefault use the collationof thecolumn. However,
this index cannot accelerate queries that involve some other collation. So if queries of the form, say,
SELECT
*
FROM test1c WHERE content >
constant
COLLATE "y";
are also of interest, an additional index could be created that supports the
"y"
collation, like this:
CREATE INDEX test1c_content_y_index ON test1c (content COLLATE "y");
11.11. Examining Index Usage
Although indexes in PostgreSQL do not need maintenance or tuning, it is still important to check
which indexes are actually used by the real-life query workload. Examining index usage for an indi-
vidual query is done with the EXPLAIN command; its application for this purpose is illustrated in
Section 14.1. It is also possible to gather overall statistics about index usage in a running server, as
described in Section 27.2.
It is difficult to formulate a general procedure for determining which indexes to create. There are a
number of typical cases that have been shown in the examples throughout the previous sections. A
good deal of experimentation is often necessary. The rest of this section gives some tips for that:
Always run ANALYZE first. This command collects statistics about the distribution of the values
in the table. This information is required to estimate thenumber of rows returned by a query, which
is neededby the planner to assign realistic costs to each possible query plan. In absence of any real
statistics, some default values are assumed, which are almost certain to be inaccurate. Examining
an application’s index usage without having run
ANALYZE
is therefore a lost cause. See Section
23.1.3 and Section 23.1.6 for more information.
Use real data for experimentation. Using test data for setting up indexes will tell you what indexes
you need for the test data, but that is all.
It is especially fatal to use very small test data sets. While selecting 1000 out of 100000 rows
couldbe a candidate for an index, selecting 1 out of 100 rows willhardly be, because the 100 rows
probably fit within a single disk page, andthere is no plan that canbeat sequentially fetching1 disk
page.
Also be careful when making up test data, which is often unavoidable when the application is not
yet in production. Values that are very similar, completely random, or inserted in sorted order will
skew the statistics awayfrom the distribution that real data would have.
Whenindexes are not used, it canbe usefulfor testingto force their use. Thereare run-timeparam-
eters that can turn off various plan types (see Section 18.7.1). For instance, turning off sequential
scans (
enable_seqscan
)and nested-loop joins (
enable_nestloop
), which are the most basic
332
C# PDF Sticky Note Library: add, delete, update PDF note in C#.net
Evaluation library and components enable users to annotate PDF without adobe PDF reader control installed. Able to add notes to PDF using C# source code in
adding an image to a pdf in acrobat; how to add image to pdf file
C# Create PDF from images Library to convert Jpeg, png images to
List<Bitmap> images = new List<Bitmap>(); images.Add(new Bitmap(Program.RootPath + "\\" 1.gif")); / Build a PDF document with GIF image.
add photo to pdf form; how to add picture to pdf
Chapter 11. Indexes
plans, will force the system to use a different plan. If the system still chooses a sequential scan or
nested-loop jointhenthere is probably a more fundamental reasonwhy the index is not being used;
for example, the query condition does not match the index. (What kind of query can use whatkind
of index is explained in the previous sections.)
If forcing index usage does use the index, then there are two possibilities: Either the system is
right and using the index is indeed not appropriate, or the cost estimates of the query plans are not
reflectingreality. Soyoushouldtime your querywithandwithoutindexes. The
EXPLAIN ANALYZE
command can be useful here.
If it turns out that the cost estimates are wrong, there are, again, two possibilities. The total cost
is computed from the per-row costs of each plan node times the selectivity estimate of the plan
node. The costs estimated for the plan nodes can be adjusted via run-time parameters (described
in Section 18.7.2). An inaccurate selectivity estimate is due to insufficient statistics. It might be
possible to improve this by tuning the statistics-gathering parameters (see ALTER TABLE).
If you do not succeed in adjusting the costs to be more appropriate, then you might have to resort
to forcing index usage explicitly. You might also want to contact the PostgreSQL developers to
examine the issue.
333
Chapter 12. Full Text Search
12.1. Introduction
FullTextSearching(or just textsearch) provides the capability to identifynatural-languagedocuments
that satisfy a query, and optionally to sort them by relevance to the query. The most common type
of search is to find all documents containing given query terms and return them in order of their
similarity to the query. Notions of
query
and
similarity
are very flexible and depend on the
specific application. The simplest search considers
query
as a set of words and
similarity
as the
frequency of query words in the document.
Textual search operators have existedin databases for years. PostgreSQL has
~
,
~
*
,
LIKE
,and
ILIKE
operators for textual data types, but they lack many essential properties required by modern informa-
tion systems:
There is no linguistic support, even for English. Regular expressions are not sufficient because
they cannot easily handle derived words, e.g.,
satisfies
and
satisfy
.You might miss docu-
ments that contain
satisfies
,although you probably would like to find them when searching
for
satisfy
.It is possible to use
OR
to search for multiple derived forms, but this is tedious and
error-prone (some words can have several thousand derivatives).
Theyprovidenoordering(ranking) of searchresults, which makes them ineffective whenthousands
of matching documents are found.
They tend to be slow because there is no index support, so they must process all documents for
every search.
Full text indexing allows documents to be preprocessed and an index saved for later rapid searching.
Preprocessing includes:
Parsing documents into tokens. It is useful to identify various classes of tokens, e.g., numbers,
words, complexwords, emailaddresses, sothatthey can be processeddifferently. In principle token
classes depend on the specific application, but for most purposes it is adequate to use a predefined
set of classes. PostgreSQL uses a parser to perform this step. A standard parser is provided, and
custom parsers can be created for specific needs.
Converting tokens into lexemes. A lexeme is a string, just like a token, but it has been normalized
so that different forms of the same wordare made alike. For example, normalization almostalways
includes folding upper-case letters to lower-case, and often involves removal of suffixes (such as
s
or
es
in English). This allows searches to find variant forms of the same word, without tediously
entering all the possible variants. Also, this step typically eliminates stop words, which are words
that are socommon that they are useless for searching. (In short, then, tokens are raw fragments of
the document text, while lexemes are words that are believed useful for indexing and searching.)
PostgreSQL uses dictionaries to perform this step. Various standard dictionaries are provided, and
custom ones can be created for specific needs.
Storing preprocessed documents optimized for searching. For example, each document can be rep-
resented as a sorted array of normalized lexemes. Along with the lexemes it is often desirable to
store positional information to use for proximity ranking, so that a document that contains a more
“dense” region of query words is assigned a higher rank than one with scattered query words.
Dictionaries allowfine-grainedcontrol over how tokens arenormalized. Withappropriate dictionaries,
you can:
334
Chapter 12. Full Text Search
Define stop words that should not be indexed.
Map synonyms to a single word using Ispell.
Map phrases to a single word using a thesaurus.
Map different variations of a word to a canonical form using an Ispell dictionary.
Map different variations of a word to a canonical form using Snowball stemmer rules.
Adata type
tsvector
is provided for storing preprocessed documents, along with a type
tsquery
for representing processed queries (Section 8.11). There are many functions and operators available
for these data types (Section 9.13), the most important of which is the match operator
@@
,which we
introduce in Section 12.1.2. Full text searches can be accelerated using indexes (Section 12.9).
12.1.1. What Is a Document?
Adocument is the unit of searching in a full text search system; for example, a magazine article
or email message. The text search engine must be able to parse documents and store associations
of lexemes (key words) with their parent document. Later, these associations are used to search for
documents that contain query words.
For searches within PostgreSQL, a document is normally a textual field within a row of a database
table, or possibly a combination (concatenation) of such fields, perhaps stored in several tables or
obtaineddynamically. In other words, a document canbeconstructedfrom differentparts for indexing
and it might not be stored anywhere as a whole. For example:
SELECT title || ’ ’ ||
author || ’ ’ ||
abstract || ’ ’ || body AS document
FROM messages
WHERE mid = 12;
SELECT m.title || ’ ’ || m.author || ’ ’ || m.abstract || ’ ’ || d.body AS document
FROM messages m, docs d
WHERE mid = did AND mid = 12;
Note: Actually, in these example queries,
coalesce
should be used to prevent a single
NULL
attribute from causing a
NULL
result for the whole document.
Another possibility is to store the documents as simple text files in the file system. In this case, the
database can be used to store the full text index and to execute searches, and some unique identifier
can be used to retrieve the document from the file system. However, retrieving files from outside the
database requires superuser permissions or specialfunction support, sothis is usuallyless convenient
thankeeping allthedatainside PostgreSQL. Also, keeping everything insidethe database allows easy
access to document metadata to assist in indexing and display.
For text search purposes, each document must be reduced to the preprocessed
tsvector
format.
Searching and ranking are performed entirely on the
tsvector
representation of a document — the
original text need only be retrieved when the document has been selected for display to a user. We
therefore often speak of the
tsvector
as being the document, but of course it is only a compact
representation of the full document.
335
Chapter 12. Full Text Search
12.1.2. Basic Text Matching
Full text searching in PostgreSQL is based on the match operator
@@
, which returns
true
if a
tsvector
(document) matches a
tsquery
(query). It doesn’t matter which data type is written first:
SELECT ’a fat cat sat on a mat and ate a fat rat’::tsvector @@ ’cat & rat’::tsquery;
?column?
----------
t
SELECT ’fat & cow’::tsquery @@ ’a fat cat sat on a mat and ate a fat rat’::tsvector;
?column?
----------
f
As the above example suggests, a
tsquery
is not just raw text, any more than a
tsvector
is. A
tsquery
contains search terms, which must be already-normalized lexemes, and may combine mul-
tiple terms using AND, OR, and NOT operators. (For details see Section 8.11.) There are functions
to_tsquery
and
plainto_tsquery
that are helpful in converting user-written text into a proper
tsquery
,for example by normalizing words appearing in the text. Similarly,
to_tsvector
is used
to parse and normalize a document string. So in practice a text search match would look more like
this:
SELECT to_tsvector(’fat cats ate fat rats’) @@ to_tsquery(’fat & rat’);
?column?
----------
t
Observe that this match would not succeed if written as
SELECT ’fat cats ate fat rats’::tsvector @@ to_tsquery(’fat & rat’);
?column?
----------
f
since here no normalization of the word
rats
will occur. The elements of a
tsvector
are lexemes,
which are assumed already normalized, so
rats
does not match
rat
.
The
@@
operator also supports
text
input, allowing explicit conversion of a text string to
tsvector
or
tsquery
to be skippedin simple cases. The variants available are:
tsvector @@ tsquery
tsquery
@@ tsvector
text @@ tsquery
text @@ text
The firsttwo of these we sawalready. The form
text @@ tsquery
is equivalent to
to_tsvector(x)
@@ y
.The form
text @@ text
is equivalent to
to_tsvector(x) @@ plainto_tsquery(y)
.
336
Chapter 12. Full Text Search
12.1.3. Configurations
The above are all simple text search examples. As mentioned before, full text search functionality
includes the ability to do many more things: skip indexing certain words (stop words), process syn-
onyms, and use sophisticated parsing, e.g., parse based on more than just white space. This function-
ality is controlled by text search configurations. PostgreSQL comes with predefined configurations
for many languages, and you can easily create your ownconfigurations. (psql’s
\dF
command shows
all available configurations.)
During installation an appropriate configuration is selected and default_text_search_config is set ac-
cordingly in
postgresql.conf
.If you are using the same text search configuration for the entire
cluster you can use the value in
postgresql.conf
.To use different configurations throughout the
cluster but the same configuration within any one database, use
ALTER DATABASE ... SET
.Other-
wise, you can set
default_text_search_config
in each session.
Each text search function that depends on a configuration has an optional
regconfig
argument, so
that the configuration to use can be specified explicitly.
default_text_search_config
is used
only when this argument is omitted.
To make it easier to build custom text search configurations, a configuration is built up from sim-
pler database objects. PostgreSQL’s text search facility provides four types of configuration-related
database objects:
Text search parsers break documents intotokens and classifyeach token (for example, as words or
numbers).
Text search dictionaries convert tokens to normalized form and reject stop words.
Text search templates provide the functions underlying dictionaries. (A dictionary simply specifies
atemplate anda set of parameters for the template.)
Text search configurations select a parser and a set of dictionaries to use to normalize the tokens
produced by the parser.
Text search parsers and templates are built from low-level C functions; therefore it requires C pro-
gramming ability to develop new ones, and superuser privileges to install one into a database. (There
are examples of add-on parsers and templates in the
contrib/
area of the PostgreSQL distribution.)
Since dictionaries andconfigurations just parameterize and connect together some underlyingparsers
and templates, nospecialprivilege is needed tocreate a new dictionary or configuration. Examples of
creating custom dictionaries and configurations appear later in this chapter.
12.2. Tables and Indexes
The examples in the previous sectionillustrated full text matching using simple constant strings. This
section shows howto search table data, optionally using indexes.
12.2.1. Searching a Table
It is possible todo a full text search without an index. A simple query to print the
title
of each row
that contains the word
friend
in its
body
field is:
SELECT title
FROM pgweb
WHERE to_tsvector(’english’, body) @@ to_tsquery(’english’, ’friend’);
337
Documents you may be interested
Documents you may be interested