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 versi
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: if
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, q
> 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
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 t
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 comp
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 uniq
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 seco
> 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
times change if you do
"SELECT COUNT(1) FROM stats" ?
--
:: Sergio A. Kessler ::
Linux user #64005 - http://counter.li.org
"Yaroslav Dmitriev" <[EMAIL PROTECTED]> escribió en el mensaje
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hello,
>
> Sorry if it's wrong list for the question. Could yo
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
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
> 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 requ
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,
14 matches
Mail list logo
