MANY THANKS to everyone who replied ! Keep up great work! more things (critical for very large and mission critical databases) - database row/page compression - it looks to me that there is no page/block compression available on PostgreSQL 9.4 along the lines of MS-SQL/Oracle row/page compression features? I realize that there is some compression of individual varchar/text data type columns but there is nothing like a complete row compression, index page compression and page/dictionary compression? Is that correct? database and transaction log backup compression? not available? - recovery from hardware or software corruption - suppose I am running a mission critical database (which is also relatively large, say > 1TB) and I encounter a corruption of some sort (say, due to hardware or software bug) on individual database pages or a number of pages in a database How do I recover quickly and without losing any transactions? MS-SQL and Oracle can restore individual pages (or sets of pages) or restore individual database files and then allow me to roll forward transaction log to bring back every last transaction. It can be done on-line or off-line. How do I achieve the same in PostgreSQL 9.4? One solution I see may be via complete synchronous replication of the database to another server. I am but sure what happens to the corrupt page(s) - does it get transmitted corrupt to the mirror server so I end up with same corruption on both databases or is there some protection against this? many thanks again Yuri ________________________________________ From: pgsql-general-owner@xxxxxxxxxxxxxx <pgsql-general-owner@xxxxxxxxxxxxxx> on behalf of Stephen Frost <sfrost@xxxxxxxxxxx> Sent: Sunday, 10 May 2015 1:05 AM To: Jack Christensen Cc: pgsql-general@xxxxxxxxxxxxxx Subject: Re: moving to PostgreSQL from MS-SQL and from Oracle, looking for feature comparison information * Jack Christensen (jack@xxxxxxxxxxxxxxxxxxx) wrote: > On 05/09/2015 06:33 AM, Stephen Frost wrote: > >Temporary tables will be in memory unless they overflow work_mem > >and we do support unlogged tables and tablespaces which you could > >stick out on a ramdisk if you want. > I would suggest not putting a table space on a ramdisk. According to > the docs this risks corrupting the entire cluster. > > http://www.postgresql.org/docs/9.4/static/manage-ag-tablespaces.html That warning is about reliability of the cluster, not corruption, technically speaking. Still, you're right, that comment of mine was a bit too nonchalant about it and it's an area that we do need to improve the support of by being able to deal with the realities of a ramdisk, perhaps by having a flag associated with the tablespace and then accepting that files may not exist at startup (or when we go to access them). All that said, and I won't say that I've tested it as much as I would if it was being done in a production environment, but I've used a ramdisk under a tablespace by copying what's there after creation of the tablespace and tables (which should be unlogged) that you want there and then restoring that on reboot. Might be worth a blog post about, to see if anyone else is doing that or if people have run into issues with it. It was a while ago and I don't recall anything else being needed, but it's possible I've forgotten. :) Thanks! Stephen -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
