On 8/4/2015 6:14 AM, Melvin Davidson wrote:
As additional advice, to get the best performance, you will want all
your tablespaces to be on separate spindles/disks.
EG: disk1/tblspc1
disk2/tblspc2
disk3/tblspc3
...
disk99/tblspc99
actually, I find to get best pe
As additional advice, to get the best performance, you will want all your
tablespaces to be on separate spindles/disks.
EG: disk1/tblspc1
disk2/tblspc2
disk3/tblspc3
...
disk99/tblspc99
On Tue, Aug 4, 2015 at 5:31 AM, Albe Laurenz
wrote:
> Chris Withers wrote:
> >
Chris Withers wrote:
> This raises an interesting question: can a child table be in a different
> tablespace to its parent and other children of that parent?
Yes.
Inheritance is a logical concept and is independent of physical placement.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing li
On 04/08/2015 09:11, Seref Arikan wrote:
I work in healthcare and patient centric records let me consider
multiple servers for lots and lots of patients. The
engineering team
from instagram has been sharing their experience with
postgres, which is
possib
On Tue, Aug 4, 2015 at 9:06 AM, Chris Withers
wrote:
> On 03/08/2015 08:34, Seref Arikan wrote:
>
>>
>>
>> At what point does postgres stop scaling?
>> What happens when the computational load no longer fits on one
>> machine? What are the options then?
>>
>>
>> I think it is hard to
On 03/08/2015 08:34, Seref Arikan wrote:
At what point does postgres stop scaling?
What happens when the computational load no longer fits on one
machine? What are the options then?
I think it is hard to come up with blanket responses to generic
questions such as "What happens wh
On 03/08/2015 08:40, Jony Cohen wrote:
Servers now days reach very impressive write speeds and at rather low
prices - it's simpler to split the write to 2 tables on different
tablespaces/devices than 2 servers.
This raises an interesting question: can a child table be in a different
tablespace t
On Mon, Aug 3, 2015 at 8:22 AM, Chris Withers
wrote:
> On 03/08/2015 08:15, Jony Cohen wrote:
>
>> SSD disks are cheep these days but they don't like repeated
>> writes/deletes so it might cause problems down the line (hence my first RAM
>> recommendation)
>>
>> as for keeping the raw data - you
On 03/08/2015 08:15, Jony Cohen wrote:
SSD disks are cheep these days but they don't like repeated
writes/deletes so it might cause problems down the line (hence my
first RAM recommendation)
as for keeping the raw data - you could easily do it if you use
partitions, if you have daily partitio
Hi,
I'd recommend looking into 2 solutions here, depending if you want to keep
the data or not and how "fault tolerant" is the app (could you loose data
from the last hour?)
If you could loose some data and you don't intend keeping the whole data
set - I'd look at using RAM as your storage - it's t
Hi All,
I'm curious if there are recommendations for scaling postgres to what,
for me, seems like "a lot" of data...
The app in question currently writes around 1.5 billion rows into a
table before rolling them up into tables that have a few million roll up
rows each. That 1.5 billion row ta
11 matches
Mail list logo
