Natalie Wenz writes:
> ... With the speed postgres is capable of, and the ever-falling prices
> of storage making larger, faster databases possible, has the possibility
> of changing the transaction id to a 64-bit (or even 128-bit!) value been
> considered?
Not terribly seriously --- the penaltie
Hi all,
I have a few questions related to recovering from a near-miss with
transactionid wraparound.
I'm currently running a vacuum freeze in single user mode on our largest
database (about 36 TB). It's been running for about 10 days (since the
database shut itself down to avoid xid wraparoun
I tested the hybrid approach during my months-long testing and performance
stuff, and I was a bit underwhelmed.
That said, what _I_ personally really needed was increase in peak iops. Using
spindles for "static" data (OS, some logs, and such) worked fine, but no matter
how I split up the pg st
On Aug 12, 2013, at 4:15 PM, Lonni J Friedman wrote:
> On Mon, Aug 12, 2013 at 1:05 PM, Bruce Momjian wrote:
>> On Mon, Aug 12, 2013 at 08:33:04AM -0700, Joshua D. Drake wrote:
1) Has anyone had experience with Intel 520 SSDs? Are they reliable?
When they fail, do they fail nicely (ie
On Mon, Aug 12, 2013 at 04:41:48PM -0400, David F. Skoll wrote:
> On Mon, 12 Aug 2013 16:05:04 -0400
> Bruce Momjian wrote:
>
> > On Mon, Aug 12, 2013 at 08:33:04AM -0700, Joshua D. Drake wrote:
>
> > > Put the pg_xlog on spindles, they are more than fast enough and
> > > won't eat up the write
Actually it is kinda complicated:
*dev(9.1.9, for which pgadmin3 complains w/ that error)*
postgres=# \dx+ adminpack
Objects in extension "adminpack"
Object Description
---
function pg_file_length(text)
function pg_file_read(text,bigint,bi
On Mon, 12 Aug 2013 16:05:04 -0400
Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 08:33:04AM -0700, Joshua D. Drake wrote:
> > Put the pg_xlog on spindles, they are more than fast enough and
> > won't eat up the write life of your SSDs.
> Given its small size and need for fast fsync, I have WAL
On Mon, Aug 12, 2013 at 1:05 PM, Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 08:33:04AM -0700, Joshua D. Drake wrote:
>> >1) Has anyone had experience with Intel 520 SSDs? Are they reliable?
>> >When they fail, do they fail nicely (ie, failure detected and bad drive
>> >removed from RAID array
On Mon, Aug 12, 2013 at 08:33:04AM -0700, Joshua D. Drake wrote:
> >1) Has anyone had experience with Intel 520 SSDs? Are they reliable?
> >When they fail, do they fail nicely (ie, failure detected and bad drive
> >removed from RAID array) or horribly (data silently corrupted...) ?
>
> I don't re
On Mon, 12 Aug 2013 11:01:09 -0500 (CDT)
Scott Whitney wrote:
> When you say "16 10K drives," do you mean:
I mean 8 RAID-1 pairs with data striped across the pairs. The Linux
software RAID "offset" scheme is described here:
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-r
When you say "16 10K drives," do you mean:
a) RAID 0 with 16 drives?
b) RAID 1 with 8+8 drives?
c) RAID 5 with 12 drives?
d) RAID 1 with 7+7 drives and 2 hotspares?
We moved from a 14 FC drive (15k RPM) array (6+6 with 2 hotspares) to a 6 SSD
array (2+2 with 2 hotspares) because our iops wo
On Mon, Aug 12, 2013 at 8:28 AM, David F. Skoll wrote:
>
> 3) Our current workload peaks at about 5000 transactions per second;
> you can assume about one-third to one-half of those are writes. Do
> you think we can get away with 16 10Krpm SATA drives instead of the
> SSDs?
>
pgbench peaks out a
On 08/12/2013 08:28 AM, David F. Skoll wrote:
Hi,
We run a fairly write-intensive workload and are looking at upgrading
our Pg servers. (PostgreSQL 9.1; no practical way to upgrade to 9.2 for
a while because we use what's packaged with Debian.)
apt.postgresql.org
I'm considering the foll
Hi,
We run a fairly write-intensive workload and are looking at upgrading
our Pg servers. (PostgreSQL 9.1; no practical way to upgrade to 9.2 for
a while because we use what's packaged with Debian.)
I'm considering the following configuration:
Dual 4-core Intel CPU (E5620 at 2.4GHz)
192G
Lukasz Brodziak wrote:
> I have a table which contains 5 columns the last 3 indicate wether the
> employer worked with given project or not. The values are simply Yes
> and No. What I need is a list of people who haven't worked in at least
> one project.
> So for example we have data:
>
> John Smi
Hello,
I have a table which contains 5 columns the last 3 indicate wether the
employer worked with given project or not. The values are simply Yes
and No. What I need is a list of people who haven't worked in at least
one project.
So for example we have data:
John Smith Yes No Yes
Tim Robins No
16 matches
Mail list logo
