Re: [GENERAL] Change column type from int to bigint - quickest way

> On Wed, Nov 16, 2016 at 7:49 AM, Merlin Moncure < mmonc...@gmail.com > wrote: >> On Fri, Nov 11, 2016 at 9:30 AM, Andreas Brandl < m...@andreas-brandl.de > >> wrote: >> You just posted the same question a few days ago -- were the answers >> there uns

[GENERAL] Change column type from int to bigint - quickest way

Hi, we have a pretty big table with an integer-type primary key. I'm looking for the quickest way to change the column type to bigint to avoid hitting the integer limit. We're trying to avoid prolonged lock situations and full table rewrites. I know I can hack this with an UPDATE on pg_attribu

[GENERAL] Change column type from int to bigint - quickest way

Hi, we have a pretty big table with an integer-type primary key. I'm looking for the quickest way to change the column type to bigint to avoid hitting the integer limit. We're trying to avoid prolonged lock situations and full table rewrites. I know I can hack this with an UPDATE on pg_attribu

Re: [GENERAL] Querying a time range across multiple partitions

John, > On Fri, Sep 5, 2014 at 2:17 PM, John R Pierce < pie...@hogranch.com > > wrote: >> On 9/5/2014 10:31 AM, Cal Heldenbrand wrote: >> Number of child tables: 1581 >> that's an insane number of children. We try and limit it to 50 or so >> child tables, for instance, 6 months retention by week,

Re: [GENERAL] replacing expresion in plpgsql

John, - Ursprüngliche Mail - > On 12/15/2013 4:17 PM, Andreas Brandl wrote: > > select current_timestamp, current_timestamp + interval '2' day; > > that should be interval '2 day' (note the ' moved), and for a > variable number passed as a pa

Re: [GENERAL] replacing expresion in plpgsql

Hi, - Ursprüngliche Mail - > > Hi, i have a function that receives a parameter which represents > days: > > > FUNCTION aaa_recharge_account(expdays integer) > > > i want to add those days to the CURRENT_DATE, but i do not know how > to do it, i have tried several ways to replace that in an

Re: [GENERAL] how much disk space does a VACUUM FULL take?

John, > Due to running low on disk space, we have recently removed a majority > of rows from a table to an archival DB. > > Although VACUUM allows disk space to be re-used, VACUUM FULL is the > only one that actively reclaims disk space for use by the OS. > http://www.postgresql.org/docs/9.0/sta

Re: [GENERAL] Postgres as In-Memory Database?

Hi Stefan, > How can Postgres be used and configured as an In-Memory Database? > we've put the data directory on our buildserver directly on a ramdisk (e.g. /dev/shm) to improve build times. Obviously you then don't care too much about durability here, so one can switch off all related settin

Re: [GENERAL] Postgres as In-Memory Database?

Edson, > Em 17/11/2013 19:26, Stefan Keller escreveu: > > Hi Edson > > > > As Rob wrote: Having a feature like an in-memory table like SQLite > > has > > [1] would make application cahces obsoleteand interesting to > > discuss > > (but that was'nt exactly what I asked above). > > Hi, Stephan, >

[GENERAL] PITR / progress

Hi, I'm currently doing a point in time recovery with a recovery_target_time set. As it takes quite a while, I was wondering if there is a way to see the progress in terms of 'realtime' somehow? Is there any way of getting the timestamp of the last replayed transaction or the like? I know that

[GENERAL] progress of PITR

Hi, I'm currently doing a point in time recovery with a recovery_target_time set. As it takes quite a while, I was wondering if there is a way to see the progress in terms of 'realtime' somehow? Is there any way of getting the timestamp of the last replayed transaction or the like? I know that

[GENERAL] Determine dead files

Hi, we have a streaming replication running and kind of suspect that the slave contains dead files caused by an abort of a huge transaction. I'd like to ask how we can be sure that those files are dead. The details are: * PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.6.real

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

> Andreas Brandl writes: > >> The planner doesn't use n_live_tup; > > > I'm just curious: where does the planner take the (approximate) > > row-count from? > > It uses the tuple density estimated by the last vacuum or analyze > (viz, > reltu

Re: [GENERAL] Statistics mismatch between n_live_tup and actual row count

Hi, > Andreas Brandl writes: > > we're currently investigating a statistics issue on postgres. We > > have some tables which frequently show up with strange values for > > n_live_tup. If you compare those values with a count on that > > particular table, there is

[GENERAL] Statistics mismatch between n_live_tup and actual row count

Hi, we're currently investigating a statistics issue on postgres. We have some tables which frequently show up with strange values for n_live_tup. If you compare those values with a count on that particular table, there is a mismatch of factor 10-30. This causes the planner to come up with very

[GENERAL] PITR on different machine/architecture?

Hi, we are implementing archiving/PITR for a postgresql instance operating on OpenBSD/64-bit. Is it possible to restore the backup on a completely different machine (i.e. other OS/32-bit)? What about restoring on (slightly) different versions of postgresql? Thanks! Best regards, Andreas --