On Tue, Nov 20, 2018 at 08:34:20AM -0500, Stephen Frost wrote:
> > Anyway, to bring data from JSON to a relational model is out of topic
> > for the current discussion, since we are actually questioning if
> > Postgres is a good replacement for Mongo when handling JSON data.
>
> This narrow viewpo
On Wed, Nov 21, 2018 at 9:48 AM Thomas Kellerer wrote:
>
> Stephen Frost schrieb am 20.11.2018 um 18:28:
> > Oh yes, having a dictionary would be a great start to reducing the size
> > of the jsonb data, though it could then become a contention point if
> > there's a lot of new values being insert
Stephen Frost schrieb am 20.11.2018 um 18:28:
> Oh yes, having a dictionary would be a great start to reducing the size
> of the jsonb data, though it could then become a contention point if
> there's a lot of new values being inserted and such. Naturally there
> would also be a cost to pulling th
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Tue, Nov 20, 2018 at 11:28 AM Stephen Frost wrote:
> > Oh yes, having a dictionary would be a great start to reducing the size
> > of the jsonb data, though it could then become a contention point if
> > there's a lot of new values bein
On Tue, Nov 20, 2018 at 11:28 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
> > > * Merlin Moncure (mmonc...@gmail.com) wrote:
> > > > On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost
> > > > wrote
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
> > * Merlin Moncure (mmonc...@gmail.com) wrote:
> > > On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > > > Looks like a lot of the difference being seen and the comments made
On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > > Looks like a lot of the difference being seen and the comments made
> > > about one being faster than the other are
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > Looks like a lot of the difference being seen and the comments made
> > about one being faster than the other are because one system is
> > compressing *everything*, while PG (quite
On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> Looks like a lot of the difference being seen and the comments made
> about one being faster than the other are because one system is
> compressing *everything*, while PG (quite intentionally...) only
> compresses the data sometimes- once it
Hi again,
On 11/20/18 2:34 PM, Stephen Frost wrote:
>> I agree with you the compression is playing a role in the comparison.
>> Probably there is a toll to pay when the load is high and the CPU
>> stressed from de/compressing data. If we will be able to bring our
>> studies that further, this is
Greetings,
* Fabio Pardi (f.pa...@portavita.eu) wrote:
> thanks for your feedback.
We prefer on these mailing lists to not top-post but instead to reply
inline, as I'm doing here. This helps the conversation by eliminating
unnecessary dialogue and being able to make comments regarding specific
p
Hi Stephen,
thanks for your feedback.
I agree with you the compression is playing a role in the comparison.
Probably there is a toll to pay when the load is high and the CPU
stressed from de/compressing data. If we will be able to bring our
studies that further, this is definitely something we wo
Greetings,
* Fabio Pardi (f.pa...@portavita.eu) wrote:
> We are open to any kind of feedback and we hope you enjoy the reading.
Looks like a lot of the difference being seen and the comments made
about one being faster than the other are because one system is
compressing *everything*, while PG (q
Hi list,
For your consideration I'm submitting you a research I made together with my
colleague Wouter.
We compared the 2 databases for our specific use case on medical data stored
using FHIR standard.
This is indeed a very restrictive use case, and moreover under read only
circumstances. We
14 matches
Mail list logo
