"Thomas A. Lowery" <[EMAIL PROTECTED]> writes:
> Can I force the use of an index?
Try "set enable_seqscan = off". But on the basis of what you've shown,
it's not obvious that an indexscan will be faster. Is the planner's
estimate that 139654 rows will match f_state = 'PA' in the right
ballpark?
I've the task of porting a current Oracle application to PostgreSQL.
Database: 7.2.1
OS: Linux 2.4.9-13smp
I've an odd thing happening with a query. Using a simple table:
Table "state_tst"
Column | Type | Modifiers
-+--+---
id
1. what is necessary to use japanese at the psql command prompt? I changed the encoding to SJIS.
2, does any one know of any jdbc examples with a japanese postgresql backend.
Thanks,
Christopher smithDo You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
No tengo ningun problema, solo quisiera saber que debo hacer en caso de que
la base se llege a caer y no quiera funcionar.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmai
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> No Problem- we'll do that. Is there a table that contains the mapping from
> the database object names to the actual filenames?
Look at the relfilenode column of pg_class for the individual file
names, and at the OID column of pg_database for the di
Tom-
No Problem- we'll do that. Is there a table that contains the mapping from
the database object names to the actual filenames?
-Nick
> Next time it happens, would you shut down the
> postmaster and make a copy of pg_attribute and its indexes (the physical
> files) to send to me, before you
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> We've just seen the following error for a second time since upgrading to
> 7.2.1-2:
> cannot find attribute 1 of relation
> The first time, Tom Lane helped us by suggesting a reindex of pg_attribute.
> I tried this on the second case as well, and it
Hi-
We've just seen the following error for a second time since upgrading to
7.2.1-2:
cannot find attribute 1 of relation
The first time, Tom Lane helped us by suggesting a reindex of pg_attribute.
I tried this on the second case as well, and it solved the problem.
At this point, I'm concerne
Scott Taylor <[EMAIL PROTECTED]> writes:
> Could anyone tell me what (if anything) I can do if I upgraded from 7.1.3 to
> 7.2, without doing backup (pg_dump). I cannot read my dataset because it is
> incompatible with new version. Could you give me the commands?
You're going to have to reinstal
Tom, Joe:
> Yup, that's the standard hack.
Thanks very much! This saved us hours.
-Nick
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Hi Scott,
You must dump and reload the data
when upgrading from 7.1.x to 7.2.x
I feel i had read like that in the release notes
for 7.2.x
are u facing any problem in pg_dumping ??
regds.
mallah.
On Tuesday 21 May 2002 04:12 pm, Scott Taylor wrote:
> Could anyone tell me what (if anything) I
Could anyone tell me what (if anything) I can do if I upgraded from 7.1.3 to
7.2, without doing backup (pg_dump). I cannot read my dataset because it is
incompatible with new version. Could you give me the commands?
I have Red Hat 7.3 (running SQL Ledger)
my data set is at: /usr/local/www/sql-
-- Forwarded Message --
Subject: Upgrade to 7.2
Date: Tue, 21 May 2002 11:42:28 +0100
From: Scott Taylor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Could anyone tell me what (if anything) I can do if I upgraded from 7.1.3 to
7.2, without doing backup (pg_dump). I cannot read m
13 matches
Mail list logo
