Re: [GENERAL] Issue with pg_toast tables

Hello 2012/11/26 Ranjeet Dhumal : > Hi All , > > Am facing one problem related to pg_toast table , its grown very huge upto > 31GB , even am vacuuming(not full) it daily , my fsm parameters are default, > can anyone tell how to decrease the size , if am firing any query on > gen_bulk_20121126 its

[GENERAL] Issue with pg_toast tables

Hi All , Am facing one problem related to pg_toast table , its grown very huge upto 31GB , even am vacuuming(not full) it daily , my fsm parameters are default, can anyone tell how to decrease the size , if am firing any query on gen_bulk_20121126 its response time is very slow as compared to fe

Re: [GENERAL] Regarding getting source from 9.2.0beta1 and 9.2beta1.

Hari Babu writes: > When I was trying get the source code from ftp source, I found that > 9.2.0beta1 and 9.2beta1 are pointing to > 9.2.0beta1 source code. Is it intentional or Is there any source code > difference between 9.2.0beta1 and 9.2beta1? We do not use version strings like "9.2.0beta1".

[GENERAL] Regarding getting source from 9.2.0beta1 and 9.2beta1.

Hi, When I was trying get the source code from ftp source, I found that 9.2.0beta1 and 9.2beta1 are pointing to 9.2.0beta1 source code. Is it intentional or Is there any source code difference between 9.2.0beta1 and 9.2beta1? Regards, Hari babu.

Re: [GENERAL] High SYS CPU - need advise

RAID10 -- vlad On 11/24/2012 3:17 PM, Gavin Flower wrote: Curious, what is your RAID configuration? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Query caching absent "query caching"

2012/11/25 Bexley Hall : > Hi Pavel, > > On 11/24/2012 9:47 PM, Pavel Stehule wrote: >> >> Hello >> >> you can try use plperl as cache >> >> >> http://okbob.blogspot.cz/2007/12/using-shared-as-table-cache-in-plperl.html > > > But how is this any different than just creating a named/shared > table m

Re: [GENERAL] large INSERT leads to "invalid memory alloc"

Stefan Froehlich writes: > On Sun, Nov 25, 2012 at 06:57:22PM +0100, Pavel Stehule wrote: >>> | INSERT INTO a (id, fkid, displayorder, name, description, internal, >>> mimetype, mimedata, filesize) VALUES (73,6,5, E'Seefeld.rar', E'Seefeld',0, >>> E'application/octet-stream',decode('5261...0700'

Re: [GENERAL] Query caching absent "query caching"

Hi Kevin, On 11/25/2012 8:10 AM, Kevin Grittner wrote: Bexley Hall wrote: Specifically, I have several computationally expensive functions that derive their results from specific values of these base types. *Solely*. (For example, area() when applied to a given "circle" always yields the same

Re: [GENERAL] large INSERT leads to "invalid memory alloc"

2012/11/25 Stefan Froehlich : > On Sun, Nov 25, 2012 at 06:57:22PM +0100, Pavel Stehule wrote: >> > | INSERT INTO a (id, fkid, displayorder, name, description, internal, >> > mimetype, mimedata, filesize) VALUES (73,6,5, E'Seefeld.rar', >> > E'Seefeld',0, E'application/octet-stream',decode('5261.

Re: [GENERAL] Query caching absent "query caching"

Hi Pavel, On 11/24/2012 9:47 PM, Pavel Stehule wrote: Hello you can try use plperl as cache http://okbob.blogspot.cz/2007/12/using-shared-as-table-cache-in-plperl.html But how is this any different than just creating a named/shared table manually? And, how do further/additional accesses (by

Re: [GENERAL] large INSERT leads to "invalid memory alloc"

On Sun, Nov 25, 2012 at 06:57:22PM +0100, Pavel Stehule wrote: > > | INSERT INTO a (id, fkid, displayorder, name, description, internal, > > mimetype, mimedata, filesize) VALUES (73,6,5, E'Seefeld.rar', E'Seefeld',0, > > E'application/octet-stream',decode('5261...0700', 'hex'),311484587); > Atte

Re: [GENERAL] What happens to a primary key b-tree index when a table tuple is deleted by a transaction?

On 25 November 2012 18:03, Luby Liao wrote: > If the b-tree changes for the transaction, would it not become broken for > other transactions? > Can anyone tell me how Postgres handles this? Thank you, Luby Unfortunately, that book is a little out of date. Even with a unique index, there can si

Re: [GENERAL] What happens to a primary key b-tree index when a table tuple is deleted by a transaction?

Hello 2012/11/25 Luby Liao : > Bruce Momjian's book says that (p109) > >> When POSTGRESQL updates a row, it keeps the old copy of the row in the >> table file and writes a new one. The old row is marked as expired, and used >> by other transactions still viewing the database in its prior state. >>

[GENERAL] What happens to a primary key b-tree index when a table tuple is deleted by a transaction?

Bruce Momjian's book says that (p109) When POSTGRESQL updates a row, it keeps the old copy of the row in the > table file and writes a new one. The old row is marked as expired, and used > by other transactions still viewing the database in its prior state. > Deletions are similarly marked as ex

Re: [GENERAL] large INSERT leads to "invalid memory alloc"

Hello 2012/11/25 Stefan Froehlich : > While converting a mysql database into postgres, I stumbled over the > following problem: > > | INSERT INTO a (id, fkid, displayorder, name, description, internal, > mimetype, mimedata, filesize) VALUES (73,6,5, E'Seefeld.rar', E'Seefeld',0, > E'application/

[GENERAL] large INSERT leads to "invalid memory alloc"

While converting a mysql database into postgres, I stumbled over the following problem: | INSERT INTO a (id, fkid, displayorder, name, description, internal, mimetype, mimedata, filesize) VALUES (73,6,5, E'Seefeld.rar', E'Seefeld',0, E'application/octet-stream',decode('5261...0700', 'hex'),31148

Re: [GENERAL] Query caching absent "query caching"

Bexley Hall wrote: > Specifically, I have several computationally expensive > functions that derive their results from specific values of > these base types. *Solely*. (For example, area() when > applied to a given "circle" always yields the same result... > though this is a trivial/inexpensive fu

Re: [GENERAL] Revoke "drop database" even for superusers?

On Fri, 2012-11-23 at 23:56 -0200, Edson Richter wrote: > Wordeful! > > Guillaume, Thanks. > > I"ll give a try for few weeks in the development and test databases > before put in production. > Make sure you test it thoroughly. As I said, it's more an example code, than a production-ready code.