On Thu, Jun 16, 2011 at 5:12 PM, Greg Smith wrote:
> On 06/16/2011 03:04 PM, Merlin Moncure wrote:
>>
>> I don't necessarily agree. the drives are SLC and have the potential
>> to have a much longer lifespan than any MLC drive, although this is
>> going to depend a lot on the raid controller if wr
On 06/16/2011 03:04 PM, Merlin Moncure wrote:
I don't necessarily agree. the drives are SLC and have the potential
to have a much longer lifespan than any MLC drive, although this is
going to depend a lot on the raid controller if write caching is
disabled. Also, reading the post that got all th
Hello, postgresql guru's
When developing ticket export mechanism for our ticketing system I
thought the wise thing would be to generate the result (XML file) in
stored function. This worked fine for small datasets, but for the larger
ones I see it takes much longer to generate the document tha
On Thu, Jun 16, 2011 at 1:43 PM, Greg Smith wrote:
> These drives are one of the worst choices on the market for PostgreSQL
> storage. They're unusably slow if you disable the caches, and even that
> isn't guaranteed to work. There is no way to make them safe. See
> http://wiki.postgresql.org/w
On Thu, Jun 16, 2011 at 12:43 PM, Greg Smith wrote:
> There are already three layers involved here:
>
> -Database shared_buffers cache
> -Operating system read/write cache
> -RAID controller cache
>
> I would be skeptical that adding a fourth one near the bottom of this stack
> is likely to help a
On 06/16/2011 11:09 AM, Haestan wrote:
The cheaper option would be to buy 15k Seagate SAS disks with a 3ware
9750SA (battery backed) controller. Does it matter whether to use a
4-disk RAID10 or 2x 2-disk RAID1 (system+pg_xlog , pg_data) setup? Am
I right that both would be faster than just using
On 06/16/2011 12:25 PM, Magnus Hagander wrote:
PostgreSQL 9.0 is unable to use an index scan to find min/max on a
partitioned table. 9.1, however, can do that.
Unfortunately this is true. You can fake it this way though:
/**
* Return the Maximum INT Value for a Partitioned Table Column
*
* @p
On 2011-06-16 17:09, Haestan wrote:
I am evaluating hardware for a new PostgreSQL server. For reasons
concerning power consumption and available space it should not have
more than 4 disks (in a 1U case), if possible. Now, I am not sure what
disks to use and how to layout them to get the best perf
On Thu, Jun 16, 2011 at 10:09 AM, Haestan wrote:
> Hi,
>
> I am evaluating hardware for a new PostgreSQL server. For reasons
> concerning power consumption and available space it should not have
> more than 4 disks (in a 1U case), if possible. Now, I am not sure what
> disks to use and how to layo
On Thu, Jun 16, 2011 at 15:55, Svetlin Manavski
wrote:
> Hi everybody,
>
> I am running PostgreSQL 9.0 which performs well in most of the cases. I
> would skip all the parameters if these are not necessary.
> I need to frequently (every min) get the max value of the primary key column
> on some ta
On 2011-06-16 15:55, Svetlin Manavski wrote:
Hi everybody,
I am running PostgreSQL 9.0 which performs well in most of the cases. I
would skip all the parameters if these are not necessary.
I need to frequently (every min) get the max value of the primary key column
on some tables, like this cas
Hi everybody,
I am running PostgreSQL 9.0 which performs well in most of the cases. I
would skip all the parameters if these are not necessary.
I need to frequently (every min) get the max value of the primary key column
on some tables, like this case which works perfectly well:
explain analyze
Hi,
I am evaluating hardware for a new PostgreSQL server. For reasons
concerning power consumption and available space it should not have
more than 4 disks (in a 1U case), if possible. Now, I am not sure what
disks to use and how to layout them to get the best performance.
The cheaper option woul
13 matches
Mail list logo
