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/pagecompression features?
I realize that there is some compression of individual varchar/text data type columns but there is nothing like a
completerow 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
corruptionof 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
ofpages) or restore individual database files and then allow me to roll forward transaction log to bring back every
lasttransaction. It can be done on-line or off-line. How do I achieve the same in PostgreSQL 9.4? One solution I see
maybe 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
theresome protection against this?
many thanks again
Yuri
________________________________________
From: pgsql-general-owner@postgresql.org <pgsql-general-owner@postgresql.org> on behalf of Stephen Frost
<sfrost@snowman.net>
Sent: Sunday, 10 May 2015 1:05 AM
To: Jack Christensen
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] moving to PostgreSQL from MS-SQL and from Oracle, looking for feature comparison information
* Jack Christensen (jack@jackchristensen.com) 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
