C:\Program Files\PostgreSQL\8.0\bin>postgres --version
postgres (PostgreSQL) 8.0.3
- Original Message -
From: "Alvaro Herrera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, March 25, 2008 1:55 PM
Subject: Re: [BUGS] BUG: PG do not use index
[EMAIL PROTECTED] wrote:
The standard question: when was the last time you did a vacuum analyze
on this table?
Never did.
Fortunately, The Auto-Vacuum Daemon monitors table activity and performs
VACUUMs when necessary. This eliminates the need for administrators to worry
about disk space recovery in all but the most
The standard question: when was the last time you did a vacuum analyze
on this table?
Now I done:
1. vacuum full
2. analyze
3. analyze akh_testing_result
4. reindex table akh_testing_result
5. explain select count(*) from akh_testing_result
Aggregate (cost=206372.95..206372.95 rows=1 width=0)
The following bug has been logged online:
Bug reference: 4061
Logged by: Julius Tuskenis
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.7
Operating system: WinXp
Description:after backup/restore pg_attrdef.adsrc column lacks
schema name.
Details:
Problem w
On 2008-03-26 09:41, [EMAIL PROTECTED] wrote:
> 5. explain select count(*) from akh_testing_result
> Aggregate (cost=206372.95..206372.95 rows=1 width=0)
> -> Seq Scan on akh_testing_result (cost=0.00..184804.56 rows=8627356
> width=0)
You will always get seq scan when you select count(*) w
Ok. thx for answer.
When upgrading from 8.0 to 8.3
(http://www.postgresql.org/docs/8.3/interactive/install-upgrading.html)
if those error messages are normal?
C:\Program Files\PostgreSQL\8.3\bin>psql -d postgres -U root -W -f
../../pg_dump
new 2>&1 > c:/restore.log
Password for user root:
Pa
Mark Steben wrote:
> Yes, there are transactions that predate the start time of the vacuum full.
> However those transactions do not touch the table being vacuumed, they have
> nothing to do with it. Is this the expected behavior?
Yes. The system has no way to know that they will not examine th
Yes, there are transactions that predate the start time of the vacuum full.
However those transactions do not touch the table being vacuumed, they have
nothing to do with it. Is this the expected behavior?
Mark Steben
Senior Database Administrator
@utoRevenueT
A Dominion Enterprises Company
480
In response to [EMAIL PROTECTED]:
> > The standard question: when was the last time you did a vacuum analyze
> > on this table?
>
> Never did.
That's your problem. Without updated statistics on that table, PostgreSQL
probably thinks that it's so small that an index scan wouldn't be any
faster.
"Julius Tuskenis" <[EMAIL PROTECTED]> writes:
> Problem with backup/restore databases with schemas other than public. After
> restoring pg_attrdef.adsrc doesn't contain schema name of the sequence -
> only sequence itself. It is big problem then using Zeos lib components for
> Delphi, becouse they
Hi,
I tried DISTINCT MAX() on the 8.2 and 8.3 as below.
8.2.6
==
yamaguti=# create table t1 (i int, j int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"t1_pkey" for table "t1" CREATE TABLE
yamaguti=# insert into t1 select g, g from gen
The following bug has been logged online:
Bug reference: 4063
Logged by: John Whitley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Windows XP SP2, Windows Server 2k3
Description:psql locks up on pager during dump restore
Details:
On a
The following bug has been logged online:
Bug reference: 4064
Logged by: saturn five
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: winxp(sp2)
Description:the 'PostgreSQL Database Server 8.3' service auto
shutdown
Details:
C:\Program Fi
I have uploaded few shape files to posgres by using shp2pgsql followed by psql
commands. Data was loaded to the database without any problems. However when I
try to view the geometry column of some of the loaded files by using PgAdmin
III edit data display I see blank geometry columns, and executi
The following bug has been logged online:
Bug reference: 4065
Logged by: Nahum Castro
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Windows XP SP2
Description:Error on psql windows client
Details:
When i write on psql
#quit;
Postgres.e
Taiki Yamaguchi <[EMAIL PROTECTED]> writes:
> If a column has a primary-key constraint, DISTINCT MAX() fails on 8.3.
> I know that the DISTINCT in this query has no meanings, but I wasn't
> certain that this was an intended behaviour or not (a bug). If it was a
> bug, would it be fixed in the futu
16 matches
Mail list logo
