Thanks Tom for sharing with all of us your experiences; they're really
valuable in many aspect.
In the end the problem comes from the idea that every LDP-R holds its own
context/graph. The LDP data access relies in Sesame, and probably moving it
down to a native SQL access (like we did for SPARQL)
Reviving a somewhat dead thread with an update:
Previously, we had run into problems with the Posgresql query planner and
its use of generic query plans for prepared queries from Marmotta. We've
been able to mitigate this in the past by:
- Upgrading to PSQL 9.4, which is much less aggressive ab
Hi Tom,
On Thu, Nov 5, 2015 at 6:12 PM, Tom Johnson wrote:
>
> We can confirm that upgrading to PSQL 9.2+ (we are using 9.4) has
> significant performance benefits on LDP requests. GET requests that had
> been taking between 10 and 50 seconds are now observed at around 1/10 of a
> second, with mu
Hi all,
We've been doing some more work on LDP performance since our previous
message, and wanted to send a quick update.
We can confirm that upgrading to PSQL 9.2+ (we are using 9.4) has
significant performance benefits on LDP requests. GET requests that had
been taking between 10 and 50 seconds
Hi all,
We've been having problems with performance on all LDP requests for the
past week or so, following the changes described in the quoted thread.
I've tracked our current issue down to a quirk of PREPARE statements used
by Kiwi when building Postgresql queries. In short, the use of PREPARE
