Re: [GENERAL] pgp encryption functions

i have to ask ..any relation to guru charles petzold? http://en.wikipedia.org/wiki/Charles_Petzold Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorge

Re: [GENERAL] Why the mismatch? {row size reported by VACUUM} vs. {table size on disk / number of rows} vs. {sum of column type sizes}

"Vlad Romascanu" writes: > PostgreSQL 8.3.3, on Win32. > I have a table with 8 fixed-size (integer-type) columns: 6 x int8, 1 x > integer, 1 x int2. All columns have storage=plain. Have explicitly set > FILLFACTOR=100 and WITHOUT OIDS just so there's no misunderstanding. > Expected row size,

[GENERAL] Why the mismatch? {row size reported by VACUUM} vs. {table size on disk / number of rows} vs. {sum of column type sizes}

PostgreSQL 8.3.3, on Win32. I have a table with 8 fixed-size (integer-type) columns: 6 x int8, 1 x integer, 1 x int2. All columns have storage=plain. Have explicitly set FILLFACTOR=100 and WITHOUT OIDS just so there's no misunderstanding. Expected row size, based solely on data types and mi

[GENERAL] pgp encryption functions

Hello, I'm trying to use the pgp_pub_encrypt and pgp_pub_decrypt_bytea functions to store some data in my db. This is how I encrypt: INSERT INTO "Test"( "test") VALUES (pgp_pub_encrypt('test', dearmor('-BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2.0.12 (MingW32) mQENB

Re: [GENERAL] slony issues.

On Sat, 2009-11-07 at 11:59 -0700, Scott Marlowe wrote: > Thanks I'll take a look. I'm afraid that I might not get much out of > it if the cost is hidden by the function. But it's a start. You should be able to get the cost of any SPI executed in the function by using auto_explain.log_nested_sta

Re: [GENERAL] slony issues.

On Sat, Nov 7, 2009 at 10:57 AM, Jeff Davis wrote: > On Sat, 2009-11-07 at 09:23 -0700, Scott Marlowe wrote: >> I already asked this basic question on the slony mailing lists, but >> they seem kinda quiet this week. >> >> So, I've got a database with about 30,000 objects in it, and running >> the

Re: [GENERAL] slony issues.

On Sat, 2009-11-07 at 09:23 -0700, Scott Marlowe wrote: > I already asked this basic question on the slony mailing lists, but > they seem kinda quiet this week. > > So, I've got a database with about 30,000 objects in it, and running > the setaddtable() function is taking about 30 seconds, and spi

[GENERAL] slony issues.

I already asked this basic question on the slony mailing lists, but they seem kinda quiet this week. So, I've got a database with about 30,000 objects in it, and running the setaddtable() function is taking about 30 seconds, and spinning a CPU 100% while doing it. Any suggestions on indexes, or c

Re: [GENERAL] WAL shipping to two machines (PITR)

On Sat, Nov 07, 2009 at 08:10:23AM -0500, Geoffrey wrote: > We now want to add a second PITR machine that is in a remote location. > The question is, what is the best solution for such an effort? We've > considered shipping the wal files to both locations, but the concern is > that if one fails

Re: [GENERAL] alter table is taking a long time

On Sat, Nov 07, 2009 at 10:48:14AM +0200, Johan Nel wrote: > update pg_attribute set attlen = 4 + > where attname = 'yourcolumnname' > > That will take only a couple of milliseconds to do. It will also update *every* column with that name. Something involving the "attrelid" would be much safer.

Re: [GENERAL] WAL shipping to two machines (PITR)

Geoffrey wrote: Geoffrey wrote: We currently have a PITR solution in place that is facilitated via WAL shipment. This is implemented on 13 databases, where the two primary machines which contain the production databases and the PITR machine are physically located in the same facility. We no

Re: [GENERAL] WAL shipping to two machines (PITR)

Geoffrey wrote: We currently have a PITR solution in place that is facilitated via WAL shipment. This is implemented on 13 databases, where the two primary machines which contain the production databases and the PITR machine are physically located in the same facility. We now want to add a s

[GENERAL] WAL shipping to two machines (PITR)

We currently have a PITR solution in place that is facilitated via WAL shipment. This is implemented on 13 databases, where the two primary machines which contain the production databases and the PITR machine are physically located in the same facility. We now want to add a second PITR machin

Re: [GENERAL] alter table is taking a long time

is just a varchar field that i want to make it bigge ,right now the alter table is working for over 6 hours On 7 nov., 08:41, michael.har...@ericsson.com ("Michael Harris") wrote: > Hi, > > I recently had to do something similar: change one column from INT to BIGINT > in a table which has inherit

Re: [GENERAL] alter table is taking a long time

On 7 nov., 08:41, michael.har...@ericsson.com ("Michael Harris") wrote: > Hi, > > I recently had to do something similar: change one column from INT to BIGINT > in a table which has inherited to a depth of 3 and where some of the child > tables had millions of records. > > All affected tables hav

Re: [GENERAL] alter table is taking a long time

Hi, stanciuthe...@gmail.com wrote: is just a varchar field that i want to make it bigge ,right now the alter table is working for over 6 hours You can try to update the pg_attribute table directly. Just first do some select statements to ensure you only update what you really want to. Also