Hi all,
I have a cluster database with a master and slave ,
the size of master database is very high reltive to slave
while both have approximatly same data.
On master
# select pg_size_pretty(pg_database_size('table_name'));
pg_size_pretty
15 GB
(1 ro
On 5 Srpen 2011, 9:00, Vivekkumar Pandey wrote:
> Hi all,
>
>I have a cluster database with a master and slave ,
> the size of master database is very high reltive to slave
>while both have approximatly same data.
What version of PostgreSQL is this, what kind of cluster, and what
Hi Tomas,
I am using the slony cluster and both the database have the same Data.
So Please provide the appropriate solution
On Fri, Aug 5, 2011 at 12:47 PM, Tomas Vondra wrote:
> On 5 Srpen 2011, 9:00, Vivekkumar Pandey wrote:
>> Hi all,
>>
>> I have a cluster database with a mas
On Fri, Aug 5, 2011 at 2:37 AM, Vivekkumar Pandey
wrote:
>
> Hi Tomas,
>
> I am using the slony cluster and both the database have the same Data.
>
> So Please provide the appropriate solution
>
> On Fri, Aug 5, 2011 at 12:47 PM, Tomas Vondra wrote:
> >
> > That suggests you're using somet
Hi,
slon process is running on the system .
Now , I have a question that Why dead tupples are remains in the table
while AUTOVACUUM process running at the fixed interval of time without
any error.
Also suggest the Query that can view the dead tuples in the table.
Thanks for instant reply...
O
On 5 Srpen 2011, 10:52, Vivekkumar Pandey wrote:
> Hi,
> slon process is running on the system .
>
> Now , I have a question that Why dead tupples are remains in the table
> while AUTOVACUUM process running at the fixed interval of time without
> any error.
Well, because that's how vacuum works. V
Hello ppl,
for few years I have problem when update double precision field. I have
table and few double precision columns, here is example:
sumall double precision,
sumin double precision,
My php script do:
$get = 2.40
and sql code is:
UPDATE table1 SET sumall = sumall + $get WHERE id = 1
I am using a library which is emitting SQL like this SELECT COUNT(*)
FROM batches LIMIT 15 OFFSET 15 the library fails because on postgres
this query returns nothing (not even zero as a result). Presumably it
returns some valid value on mysql and other databases.
Other than hacking the library is
Hi,
I think problem is in OFFSET 15
It means return rows after row 15... because of SELECT COUNT(*)
FROM batches LIMIT 15 returns 1 row when you add OFFSET 15 - it returns
nothing... because of there is no more than 15 rows...
I am not sure u can do something else then to change library to rem
Condor writes:
> Hello ppl,
> for few years I have problem when update double precision field. I
> have table and few double precision columns, here is example:
>
> sumall double precision,
> sumin double precision,
>
> My php script do:
>
> $get = 2.40
>
> and sql code is:
>
> UPDATE table1 SET
My question is why would you put an offset in a query designed to return a row
count without grouping and ordering?
> Date: Fri, 5 Aug 2011 22:51:24 +1200
> Subject: [GENERAL] Select count with offset returns nothing.
> From: timuc...@gmail.com
> To: pgsql-general@postgresql.org
>
> I am using
Tim Uckun writes:
> I am using a library which is emitting SQL like this SELECT COUNT(*)
> FROM batches LIMIT 15 OFFSET 15 the library fails because on postgres
> this query returns nothing (not even zero as a result). Presumably it
> returns some valid value on mysql and other databases.
>
> Ot
On Fri, 05 Aug 2011 07:20:01 -0400, Jerry Sievers wrote:
Condor writes:
Hello ppl,
for few years I have problem when update double precision field. I
have table and few double precision columns, here is example:
sumall double precision,
sumin double precision,
My php script do:
$get = 2.40
Hello all,
I was recently looking at the way "create temp table as" works and the manual
specifies that temp tables given the same name as an existing table will be
used instead of the permanent table. It also states that the permanent table
can be accessed via its schema-qualified name. I ma
Thank you Harald
--- On Thu, 8/4/11, Harald Fuchs wrote:
> From: Harald Fuchs
> Subject: Re: [GENERAL] hstore installed in a separate schema
> To: pgsql-general@postgresql.org
> Received: Thursday, August 4, 2011, 11:18 AM
> In article <1312401318.5199.yahoomailclas...@web120108.mail.ne1.yahoo.
On Fri, Aug 05, 2011 at 08:35:37AM -0400, JJ wrote:
> Hello all,
>
> I was recently looking at the way "create temp table as" works and the manual
> specifies that temp tables given the same name as an existing table will be
> used instead of the permanent table. It also states that the permane
On Fri, Aug 5, 2011 at 4:51 AM, Tim Uckun wrote:
> I am using a library which is emitting SQL like this SELECT COUNT(*)
> FROM batches LIMIT 15 OFFSET 15 the library fails because on postgres
> this query returns nothing (not even zero as a result). Presumably it
> returns some valid value on mys
Yea I figured it would need a subquery. I filed a ticket with the
library. Hopefully they will fix it.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
>From: pgsql-general-ow...@postgresql.org On Behalf Of Sam Nelson
>Sent: Wednesday, August 03, 2011 11:03 AM
>To: pgsql-general
>Subject: [GENERAL] Hot Standby Lag Calculation
>Hi, List,
>We're trying to calculate the amount of time that a Hot Standby slave is
>lagging behind its master, and ou
> -Original Message-
> From: Condor [mailto:con...@stz-bg.com]
> Sent: Friday, August 05, 2011 6:49 AM
> To: pgsql-general@postgresql.org
> Subject: Postgresql problem with update double precision
>
>
> Hello ppl,
> for few years I have problem when update double precision field. I have
Andrew Sullivan writes:
> On Fri, Aug 05, 2011 at 08:35:37AM -0400, JJ wrote:
>> I was recently looking at the way "create temp table as" works and the
>> manual specifies that temp tables given the same name as an existing table
>> will be used instead of the permanent table. It also states th
Tim Uckun writes:
> I am using a library which is emitting SQL like this SELECT COUNT(*)
> FROM batches LIMIT 15 OFFSET 15 the library fails because on postgres
> this query returns nothing (not even zero as a result). Presumably it
> returns some valid value on mysql and other databases.
FWIW,
Hello Dear People,
I have a few questions about the use of GiST for text search.
My situation is this:
I have a large and rapidly growing database of documents, and I want to support
text search.
The documents contain lots of words that it would be valid to search over. I think this means a GI
My use case.,
I have a system with master ---> Standby 1
---> Standby 2
replicating to 2 standby servers.
i will use
Incrementally_Updated_Backups(http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups)
for 2 puposes
1. For adding one more sta
On Fri, Aug 5, 2011 at 7:32 AM, Igor Neyman wrote:
> If you want to avoid your problem, switch to NUMERIC(precision, scale), which
> is precise data type.
> Alter the type of your "double" columns.
>
I'd suggest NUMERIC without specifying precision or scale. That gives
you the most flexibility.
On Thu, Aug 4, 2011 at 5:23 PM, David Johnston wrote:
> Currently I have a de-normalized table with two sets of “records” embedded
> (i.e., [id, item1_name, item1_amount, item2_name, item2_amount]). My goal
> is to output two records (i.e., [id, item_name, item_amount]) into an
> intermediate re
I have a table that looks like this:
homeidcity date measurement pre/post
123 san francisco 1/2/2003 1458 pre
123 san francisco NULL 1932 post
124 los angeles2/4/2005 938 pre
124 NULLNULL
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of jeffrey
Sent: Friday, August 05, 2011 12:33 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Filling null values
I have a table that looks like this:
homeidcity
On Fri, Aug 05, 2011 at 10:55:08AM -0400, Tom Lane wrote:
> Also, you can change the priority if you have a mind to, by adding
> "pg_temp" to the search_path explicitly, for example
Hey, that's cool, and it never occurred to me. The current text in
the 9.0 manual says this:
Likewise, the cur
I am trying to print values of an array one by one, but it doesn't work.
For example, if i want to print entire array at once, it does work:
CREATE OR REPLACE FUNCTION "public"."test_func" () RETURNS integer AS
$body$
declare
i int;
v_arr integer[] = '{0, 1}';
begin
v_arr[1] := 5;
v_arr[
Hello
It working on my 9.1.
postgres=# select "public"."test_func_new" ();
INFO: 1st element: 5
test_func_new
───
0
(1 row)
can you send more info about your environment?
Regards
Pavel Stehule
2011/8/5 Kiryl Mauryshchau :
> I am trying to print values of an array o
On Fri, Aug 5, 2011 at 5:26 AM, Tomas Vondra wrote:
> On 5 Srpen 2011, 10:52, Vivekkumar Pandey wrote:
>
>> Also suggest the Query that can view the dead tuples in the table.
>
> You can't see the dead tuples with a query - that's why they're called
> dead.
you can see an estimate of how many dea
I've inherited some version 9.0 databases which make use of the uuid
data type but which do not have the uuid-generate-vx() functions.
These installations are running on openSUSE 11.3 (x86_64) and were
installed (probably) from yast. I've loaded the requisite share-libs
(also via yast) (/usr/lib64
I've inherited some version 9.0 databases which make use of the uuid
data type but which do not have the uuid-generate-vx() functions.
These installations are running on openSUSE 11.3 (x86_64) and were
installed (probably) from yast. I've loaded the requisite share-libs
(also via yast) (/usr/lib64
Rob Sargent writes:
> I've inherited some version 9.0 databases which make use of the uuid
> data type but which do not have the uuid-generate-vx() functions.
> These installations are running on openSUSE 11.3 (x86_64) and were
> installed (probably) from yast. I've loaded the requisite share-lib
On 08/05/2011 05:26 PM, Tom Lane wrote:
> Rob Sargent writes:
>> I've inherited some version 9.0 databases which make use of the uuid
>> data type but which do not have the uuid-generate-vx() functions.
>> These installations are running on openSUSE 11.3 (x86_64) and were
>> installed (probably)
On 08/05/2011 05:26 PM, Tom Lane wrote:
> Rob Sargent writes:
>> I've inherited some version 9.0 databases which make use of the uuid
>> data type but which do not have the uuid-generate-vx() functions.
>> These installations are running on openSUSE 11.3 (x86_64) and were
>> installed (probably)
37 matches
Mail list logo
