On Tue, 2004-06-15 at 21:09, C. Bensend wrote:
> > Right. The only thing that will do for you is waste space with padding
> > blanks. The performance improvement you saw was due to something else,
> > which I theorize is not having to waste time reading dead space.
> >
> > Since you obviously dou
> Or do I just need to vacuum more often? I _did_ try a vacuum before
> asking the list for help, but it didn't give any improvement (just a
> vacuum analyze).
"vacuum analyse" allows dead space to be re-used, but doesn't compact the
table, you need "vacuum analyse full" for that.
I'm not sure
> Right. The only thing that will do for you is waste space with padding
> blanks. The performance improvement you saw was due to something else,
> which I theorize is not having to waste time reading dead space.
>
> Since you obviously doubt this assertion, try the same experiment except
> load
Hi Benny,
What happens if you recreate the table using varchar? I mean use the same
procedure yoused to create the table with char, but leave the definitions as
varchar.
Personally, I can't see any logical reason for char being faster. The
problem is the size of the row, each row spans multiple d
"C. Bensend" <[EMAIL PROTECTED]> writes:
>> The above transformation is a guaranteed loser in Postgres.
>By transformation, do you mean the varchar() -> char() change?
Right. The only thing that will do for you is waste space with padding
blanks. The performance improvement you saw was due
> "C. Bensend" <[EMAIL PROTECTED]> writes:
>> So, I went ahead and created an exact copy of this table, with the
>> exception of creating all character columns as type char(), not
>> varchar().
>> I was pondering if making PostgreSQL worry about the varying lengths
>> by using varchar was the prob
"C. Bensend" <[EMAIL PROTECTED]> writes:
> So, I went ahead and created an exact copy of this table, with the
> exception of creating all character columns as type char(), not varchar().
> I was pondering if making PostgreSQL worry about the varying lengths
> by using varchar was the problem...
Th
> Were those fields populated just like the varchar fields? If not, then
> the test proves little. If so, I find it hard to believe that char(x)
> would be any faster than varchar. They're all handled about the same.
Hi Scott,
Yes, the new table was populated from the data from the origina
ow <[EMAIL PROTECTED]> writes:
> insert into tableA
> select * from tableB
> where testdate >= '2000-01-01' and testdate <= '2002-12-31'
> What's happening is that pgSql gradually takes all (well, almost) physical and
> swap memory and then, I think, is getting killed by the kernel.
> 1) Is this
On Tue, 2004-06-15 at 18:58, C. Bensend wrote:
> Hey folks,
>
>I am working on a rather small, simple database. I'm running 7.3.5 on
> an OpenBSD 3.5-STABLE machine (1.3GHz, 512M RAM, IDE drive using UDMA-5).
>
>I am parsing and storing emails, so I have a lot of character string
> data
Hey folks,
I am working on a rather small, simple database. I'm running 7.3.5 on
an OpenBSD 3.5-STABLE machine (1.3GHz, 512M RAM, IDE drive using UDMA-5).
I am parsing and storing emails, so I have a lot of character string
data to worry about. In one particular table, I have 26 columns
Hi,
Just wondering if we can bring up PG after we stop it and
reindex database in the case DD corrupted?
That is our worry.
Thanks,
-Original Message-
From: Lee Wu
Sent: Tuesday, June 15, 2004 2:25 PM
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]
Subject: RE: [ADMIN] table not shown
I think
I could start the postmaster after doing
pg_resetxlog .
The docs tell that a dump reload of the database should be done.
I am trying to do that by starting a new postmaster in a seprate port
and using pg_dumpall
while i do that i get some minor errors like
ALTER USER arvind SET search_path TO 'erp'
I think data dictionary got corrupted:
mxl=# \d mxl_user_wbl
Table "public.mxl_user_wbl"
Column | Type | Modifiers
-+--+---
-
user_id | integer
"Lee Wu" <[EMAIL PROTECTED]> writes:
> Here is result:
> mxl=# select * from pg_catalog.pg_class where relname =
> 'mxl_quar_process';
> [ still no rows ]
Okay. I was wondering about bizarre ideas like a non-system table named
pg_class, but that seems ruled out now. I think you're down to the
RE
pg 7.4.2 on RH 7.3
Hi,
Am getting "Out of memory error" and pgSql is getting killed when running the
following statement in psql:
insert into tableA
select * from tableB
where testdate >= '2000-01-01' and testdate <= '2002-12-31'
TableB contains about 120 million records. The insert/select affe
Thanks Tom!
Here is result:
mxl=# select * from pg_catalog.pg_class where relname =
'mxl_quar_process';
relname | relnamespace | reltype | relowner | relam | relfilenode |
relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex |
relisshared | relkind | relnatts | relchecks | reltrigge
"Lee Wu" <[EMAIL PROTECTED]> writes:
> Here is screen shot:
> mxl=# select * from pg_class where relname = 'mxl_quar_process';
> [ no rows ]
> mxl=# select * from mxl_quar_process limit 1;
> [ data ]
That's just plain bizarre.
I'm wondering about corruption of the indexes on pg_class --- though
do a vacuum full on template1 and see if it reappears.
Robert Treat
On Tue, 2004-06-15 at 13:10, Lee Wu wrote:
> Hi Duane,
>
>
>
> It seems it is not:
>
>
>
> mxl=# show search_path;
>
> search_path
>
> --
>
> $user,public
>
> (1 row)
>
> mxl=# select current_schema(),
Title: RE: [ADMIN] table not shown
Thank you.
But this is not my case:
mxl=# select relname from pg_class where
lower(relname) = 'mxl_quar_process'; select * from mxl_quar_process limit 1;
relname
-
(0 rows)
quar_id | customer_id | domain_id | user_id
| host_i
Title: RE: [ADMIN] table not shown
Hi Duane,
It seems it is not:
mxl=# show search_path;
search_path
--
$user,public
(1 row)
mxl=# select current_schema(),
current_user;
current_schema | current_user
+--
public | postgres
> Rajesh Kumar Mallah wrote:
>>
>> Hi,
>>
>> The harddrive on which i had linked pg_xlog
>> has been lost. I have all other folders except that
>> which are in a seperate drive are present.
>>
>> Can i get my data back using pg_resetxlog ?
>
> Give it a try: create the xlog folder again and run pg_
Title: RE: [ADMIN] table not shown
Could this be a schema issue?
-Original Message-
From: Lee Wu [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 15, 2004 6:56 AM
To: Tom Lane
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] table not shown
Here is screen shot:
psql
Password:
Welcome
Here is screen shot:
psql
Password:
Welcome to psql 7.3.2, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
mxl
"Lee Wu" <[EMAIL PROTECTED]> writes:
> We have table is database which cannot be displayed by
> either \d, or \dt or pg_class.
> But we can select, DML on it.
You could not possibly be selecting from it if it's not in pg_class.
I expect this is pilot error on your part, but there's not enough inf
Rajesh Kumar Mallah wrote:
Hi,
The harddrive on which i had linked pg_xlog
has been lost. I have all other folders except that
which are in a seperate drive are present.
Can i get my data back using pg_resetxlog ?
Give it a try: create the xlog folder again and run pg_resetxlog.
Regards,
Bjoern
---
Hi,
The harddrive on which i had linked pg_xlog
has been lost. I have all other folders except that
which are in a seperate drive are present.
Can i get my data back using pg_resetxlog ?
Any Help will be greatly appreciated.
Regds
Mallah.
---(end of broadcast)---
27 matches
Mail list logo
