Hello,
I have a problem with viewing tables from my DB. The interesting thing
is that the physical files exist in the data folder but only some of
them are visible both in pgAdmin and the application that uses the DB.
What's more there's no trace of those tables in pg_class whatsoever. I
can view
Hi,
The cluster name is defined in the preamble.sk file like,
cluster name=TestCLuster;
node 1 admin conninfo = 'service=MasterSlonik host=10.2.26.53 port=5432
user=postgres password=* dbname=master11';
node 2 admin conninfo = 'service=SlaveSlonik1 host=10.2.26.54 port=5433
user=postgres
Kieren Scott wrote:
I'm trying to understand what is going on internally when doing a
VACUUM FULL on a table in 8.3.
The info you've gotten from Kevin is all correct, but you may find some
of the additional trivia in this area collected at
http://wiki.postgresql.org/wiki/VACUUM_FULL interesti
Dear all
the situation is that: I have a table, and the size is about 10M, I run the
database on Redhat Linux platform. for OS, a IO can hand 1M data, the file
system block is 4k, database block is 8k,
my question is that: when do the full table scan on the table, how many IO
will be done? 10M/1M
Hello,
I would try reindexing it is not said that it will be the case but
sometimes it may be helpful.
Regards
Luke
2010/10/5, Julius T :
> Hello, everybody
>
> recently I have found that queries on our customer database take longer to
> execute than normally.
>
> First thing we did was to log lon
Julius T wrote:
> The question is why the difference of value provided by EXPLAIN
> ANALYZE and observed one is so big?
There can be a number of reasons. The time to transmit the query
results to the client is one that jumps to mind, if the query
generates a large result set. Parts of what y
On 10/5/10 11:08 AM, Dinesh Bhandary wrote:
Hi All,
Is there an easy way to restore to a new table where the column name have been
changed but data remains the same?
For example I am trying to restore from existing system, table1(col1) to
table1(col2) and it is erroring out on the new column n
Hello, everybody
recently I have found that queries on our customer database take longer to
execute than normally.
First thing we did was to log long queries. This led to nothing as queries
logged are usually executed fast. On the other hand sometimes they take
considerable amount of time... The
Awesome, this will work. It won't retain the column name in insert
into statement. I was not sure if this will work with postgres 8.2.5 but
it does.
Thanks.
Dinesh
On 10/5/2010 11:15 AM, Kevin Grittner wrote:
Dinesh Bhandary wrote:
Is there an easy way to restore to a new table where the
There are a couple of ways. Assuming that it's the same database, and it's up
and running, you could do this:
Assuming:
table foo (col1 text, col2 int);
table bar (col2 text, col3 int);
insert into bar (select * from foo);
would stick everything from foo.col1 and foo.col2 into bar.col2 and
Dinesh Bhandary wrote:
> Is there an easy way to restore to a new table where the column
> name have been changed but data remains the same?
Restore to the old name and then rename the column?
Access the backup file and change the COPY statement to the new
column name?
If you can redo the
Hi All,
Is there an easy way to restore to a new table where the column name
have been changed but data remains the same?
For example I am trying to restore from existing system, table1(col1)
to table1(col2) and it is erroring out on the new column name even
though it is a data only restore.
That would explain it. I was neither in a transaction nor did any explicit
HOLD.
Thanks Kevin.
From: Kevin Grittner
To: pgsql-admin@postgresql.org; A J
Sent: Mon, October 4, 2010 5:20:14 PM
Subject: Re: [ADMIN] ECPG: AUTOCOMMIT and CURSORs
A J wrote:
> I a
Kieren Scott wrote:
> Could you explain what causes index bloat when running vacuum
> full?
To collapse the space, it copies tuples to locations closer to the
front of the table. The index needs to contain references to the
old and new tuple copies until the VACUUM FULL commits or rolls
back.
Thanks Kevin. That confirms what I've seen on 8.3.
Could you explain what causes index bloat when running vacuum full? I've
read that index bloat can occur, but no quite sure what is going on internally.
Kieren
> Date: Tue, 5 Oct 2010 10:24:26 -0500
> From: kevin.gritt...@wicourts.gov
> To: ki
Willy-Bas Loos wrote:
> any idea for the number of tuples?
Your best bet would be to use whatever scripting language you like
which has decent support for regular expressions. Expect to tweak
your expressions a bit as you discover the corner cases where you're
not getting the count you expect
Kieren Scott wrote:
> I'm trying to understand what is going on internally when doing a
> VACUUM FULL on a table in 8.3.
>
> I have a table that is 1GB in size, 500M is used, and 500M is free
> space. When I do a vacuum full on this table, will it either: -
>
> 1) Compact all of the used tupl
Hi,
I'm trying to understand what is going on internally when doing a VACUUM FULL
on a table in 8.3.
I have a table that is 1GB in size, 500M is used, and 500M is free space. When
I do a vacuum full
on this table, will it either: -
1) Compact all of the used tuples into free space within the
cool actually.
any idea for the number of tuples?
count all lines after COPY .* ) FROM stdin;
until \.
(but how?)
on a side note: what's the difference between the admin list and the general
list?
--
"Patriotism is the conviction that your country is superior to all others
because you were born
On Tue, 2010-10-05 at 11:03 +0530, Vishnu S. wrote:
>
> Yes. I have written a script file like the following.
>
> include ;
> init cluster (id=1, comment='hostname=10.2.26.53 port=5432');
It does not give me the $CLUSTER_NAME information.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Ha
Hi,
Yes. I have written a script file like the following.
include ;
init cluster (id=1, comment='hostname=10.2.26.53 port=5432');
Thanks & Regards,
Vishnu S
-Original Message-
From: Devrim GÜNDÜZ [mailto:dev...@gunduz.org]
Sent: Tuesday, October 05, 2010 10:59 AM
To: Vishnu S.
Cc:
Hi,
I am using Slony-I for replicating a database.I have a master database
and two slave databases in another server on the same host. I have done
all steps mentioned in
http://www.testdriveinteractive.com/files/Tutorial_All_PP_Slony_Replicat
ion.pdf, and started the Slony-I service. But the da
I have used EnterpriseDB's MigrationWizard to migrate a mysql database.
Everything went well except for:
Error Creating Index fltx_all: ERROR: index row size 2816 exceeds maximum 2712
for index "fltx_all"
Creating Index: fltx_adr
Error Creating Index fltx_adr: ERROR: index row size 2768 exceeds m
23 matches
Mail list logo
