3x200GB suggests you want to use RAID5?
Perhaps you should just pick 2x200GB and set them to RAID1. With roughly
200GB of storage, that should still easily house your "potentially
10GB"-database with ample of room to allow the SSD's to balance the
writes. But you save the investment and its pr
On Thu, May 2, 2013 at 5:11 PM, Mike McCann wrote:
> Hello,
>
> We are in the fortunate situation of having more money than time to help
> solve our PostgreSQL 9.1 performance problem.
>
> Our server hosts databases that are about 1 GB in size with the largest
> tables having order 10 million 20-b
Hello,
We are in the fortunate situation of having more money than time to help solve
our PostgreSQL 9.1 performance problem.
Our server hosts databases that are about 1 GB in size with the largest tables
having order 10 million 20-byte indexed records. The data are loaded once and
then read f
> mark.kirkw...@catalyst.net.nz wrote on 03.05.2013 00:19:
>> I think the idea of telling postgres that we are doing a load is
>> probably
>> the wrong way to go about this. We have a framework that tries to
>> automatically figure out the best plans...I think some more thought
>> about
>> how to m
mark.kirkw...@catalyst.net.nz wrote on 03.05.2013 00:19:
I think the idea of telling postgres that we are doing a load is probably
the wrong way to go about this. We have a framework that tries to
automatically figure out the best plans...I think some more thought about
how to make that understan
> On 2 May 2013 01:49, Mark Kirkwood wrote:
>
> I think we need a problem statement before we attempt a solution,
> which is what Tom is alluding to.
>
Actually no - I think Tom (quite correctly) was saying that the patch was
not a viable solution. With which I agree.
I believe the title of this
On Thu, May 2, 2013 at 9:48 AM, Simon Riggs wrote:
>>> SELECT count(k0.id)
>>> FROM k0
>>> WHERE 1 = 2
>>> OR k0.id IN (
>>> SELECT k1.k0_id
>>> FROM k1
>>> WHERE k1.k1k2_id IN (
>>> SELECT k2.k1k2_id
>>> FROM k2
>>> WHERE
On 18 April 2013 15:46, Tom Lane wrote:
> dmitry potapov writes:
>> I recently stumbled upon on what could be a planner bug or a corner case.
>> If " OR ..." is added to WHERE clause of SELECT query,
>> then the planner chooses a very inefficient plan. Consider a query:
>
>> SELECT count(k0.id)
>
On 18 April 2013 22:42, Tom Lane wrote:
> One could imagine adding planner logic that would make inferences of a
> similar sort for equalities combined with inequalities, but it would be
> vastly more complicated, and would provide useful results in vastly
> fewer queries, than the equality-propa
On 2 May 2013 01:49, Mark Kirkwood wrote:
> On 02/05/13 02:06, Tom Lane wrote:
>>
>> Mark Kirkwood writes:
>>>
>>> I am concerned that the deafening lack of any replies to my original
>>> message is a result of folk glancing at your original quick reply and
>>> thinking... incomplete problem spec
10 matches
Mail list logo
