On 9/23/16 7:14 AM, Mike Sofen wrote:
So with proper indexing, I can’t see where there will be a performance
issue.
Table bloat could become problematic. If there is a pattern where you
can predict which documents are likely to be active (say, documents that
have been modified in the last 10
On 9/23/16 12:59 PM, phb07 wrote:
Le 21/09/2016 à 23:42, Jim Nasby a écrit :
On 9/12/16 1:05 PM, phb07 wrote:
The drawback is the overhead of this added ANALYZE statement. With a
heavy processing like in this test case, it is worth to be done. But for
common cases, it's a little bit expensive.
Le 21/09/2016 à 23:42, Jim Nasby a écrit :
On 9/12/16 1:05 PM, phb07 wrote:
The drawback is the overhead of this added ANALYZE statement. With a
heavy processing like in this test case, it is worth to be done. But for
common cases, it's a little bit expensive.
You could always look at the num
From: Dev Nop Sent: Friday, September 23, 2016 3:12 AM
I’m storing thousands of independent documents each containing around 20k rows.
The larger the document, the more likely it is to be active with inserts and
updates (1000s/day). The most common read query is to get all the rows for a
single
I’m storing thousands of independent documents each containing around 20k
rows. The larger the document, the more likely it is to be active with
inserts and updates (1000s/day). The most common read query is to get all
the rows for a single document (100s/day). It will be supporting real-time
colla
