Il 23/03/2016 19:51, Jim Nasby ha scritto:
On 3/23/16 4:14 AM, Moreno Andreo wrote:
The main goal is to be *quick*. A doctor with a patient on the other
side of his desk does not want to wait, say, 30 seconds for a clinical
record to open.
Let me explain what is the main problem (actually there
On 3/23/16 4:14 AM, Moreno Andreo wrote:
The main goal is to be *quick*. A doctor with a patient on the other
side of his desk does not want to wait, say, 30 seconds for a clinical
record to open.
Let me explain what is the main problem (actually there are 2 problems).
1. I'm handling health
Il 23/03/2016 13:29, Mike Sofen ha scritto:
-Original Message-
Thomas Kellerer Wednesday, March 23, 2016 2:51 AM
Jim Nasby schrieb am 11.03.2016 um 17:37:
If the blob is in the database then you have nothing extra to do. It's handled
just like all your other data.
If it's a file in a
I have another suggestion. How about putting the images in RethinkDB?
RethinkDB is easy to set up and manage, and is scalable and easy (almost
trivial) to cluster. Many of the filesystem disadvantages you mention
would be much more easily managed by RethinkDB.
A while back I wrote a Foreign
> -Original Message-
> Thomas Kellerer Wednesday, March 23, 2016 2:51 AM
>
> Jim Nasby schrieb am 11.03.2016 um 17:37:
> > If the blob is in the database then you have nothing extra to do. It's
> > handled
> just like all your other data.
> >
> > If it's a file in a file system then you
Il 23/03/2016 10:50, Thomas Kellerer ha scritto:
Jim Nasby schrieb am 11.03.2016 um 17:37:
If the blob is in the database then you have nothing extra to do. It's handled
just like all your other data.
If it's a file in a file system then you need to:
- Have application code that knows how
Jim Nasby schrieb am 11.03.2016 um 17:37:
> If the blob is in the database then you have nothing extra to do. It's
> handled just like all your other data.
>
> If it's a file in a file system then you need to:
>
> - Have application code that knows how and where to get at the file
> - Have a
Il 11/03/2016 17:37, Jim Nasby ha scritto:
On 2/22/16 8:40 AM, Moreno Andreo wrote:
Il 18/02/2016 21:33, Jim Nasby ha scritto:
Depending on your needs, could could use synchronous replication as
part of that setup. You can even do that at a per-transaction level,
so maybe you use sync rep most
On 2/22/16 8:40 AM, Moreno Andreo wrote:
Il 18/02/2016 21:33, Jim Nasby ha scritto:
Depending on your needs, could could use synchronous replication as
part of that setup. You can even do that at a per-transaction level,
so maybe you use sync rep most of the time, and just turn it off when
Il 18/02/2016 21:33, Jim Nasby ha scritto:
Just before we go on, I have to say that I'm working on PostgreSQL for
about 10 years now, but while in the past "leave everything as it is"
worked, in the last 15 months I began to research and study how to
improve my server performance, so I'm
On 2/11/16 12:06 PM, Moreno Andreo wrote:
Now, the actual question, is:
Having a VM that can be upgraded with a click on a panel and a reboot,
and that the server fault is only related to a OS failure, should I keep
a single-server solution (but I fear that I/O throughput will become
even more
11 matches
Mail list logo
