I have the following doubts.
1. Does postgres create an index on every primary key? Usually, queries
are performed against a table on the primary key, so, an index on it
will be very useful.
2. If 'm executing a complex query and it takes 10 seconds to return the
results -- it takes 10
Dhanaraj M [EMAIL PROTECTED] writes:
I have the following doubts.
1. Does postgres create an index on every primary key? Usually,
queries are performed against a table on the primary key, so, an index
on it will be very useful.
To enforce the primary key constraint, PG creates a unique
Dhanaraj M wrote:
I have the following doubts.
1. Does postgres create an index on every primary key? Usually, queries
are performed against a table on the primary key, so, an index on it
will be very useful.
Yes, a unique index is used to enforce the primary-key.
2. If 'm executing a
On 23-May-06, at 10:24 AM, Richard Huxton wrote:
Dhanaraj M wrote:
I have the following doubts.
1. Does postgres create an index on every primary key? Usually,
queries are performed against a table on the primary key, so, an
index on it will be very useful.
Yes, a unique index is used
Dhanaraj M wrote:
I have the following doubts.
1. Does postgres create an index on every primary key? Usually, queries
are performed against a table on the primary key, so, an index on it
will be very useful.
Yes, a unique index is used to enforce the primary-key.
Well, here is an
Thank you for your help. I found that an implicit index is created for
the primary key in the current version. However, it is not done in 7.x
version.
Mark Woodward wrote:
Dhanaraj M wrote:
I have the following doubts.
1. Does postgres create an index on every primary key? Usually,
Thank you for your help. I found that an implicit index is created for
the primary key in the current version. However, it is not done in 7.x
version.
It absolutely is created in all 7.x versions of PostgreSQL.
---(end of broadcast)---
TIP 1:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Thank you for your help. I found that an implicit index is created for
the primary key in the current version. However, it is not done in 7.x
version.
It absolutely is created in all 7.x versions of PostgreSQL.
And every other version too.
So I am still interested in PostgreSQL's ability to deal with
multimillon records tables.
Postgres has no problem with multimillion row tables - many people on this
list run them - just don't do sequential scans on them if you can't afford
the time it takes.
Chris
Hello,
Sorry if it's wrong list for the question. Could you suggest some tweaks
to the PostgreSQL 7.2.1 to handle the following types of tables faster?
Here we have table stats with something over one millon records.
Obvious SELECT COUNT(*) FROM stats takes over 40 seconds to execute,
and
Here we have table stats with something over one millon records.
Obvious SELECT COUNT(*) FROM stats takes over 40 seconds to execute,
and this amount of time does not shorten considerably in subsequent
similar requests. All the databases are vacuumed nightly.
Doing a row count requires a
Christopher Kings-Lynne wrote:
Doing a row count requires a sequential scan in Postgres.
Try creating another summary table that just has one row and one column and
is an integer.
I have THREE summary tables derived from stats with different levels
of aggregation. They work quite fast,
On Fri, Aug 02, 2002 at 03:48:39PM +0400, Yaroslav Dmitriev wrote:
So I am still interested in PostgreSQL's ability to deal with
multimillon records tables.
[x-posted and Reply-To: to -general; this isn't a development
problem.]
We have tables with multimillion records, and they are fast.
13 matches
Mail list logo
