On 01/07/2016 06:30 PM, Steve Petrie, P.Eng. wrote:
Thanks to forum members for the four helpful replies, to my earlier message that initiated this thread. The replies expressed concerns, with the feasibility of my proposal to use postgres tables to store short-lived context data, for dialog continuity during website app transient sessions, with visitor browsers over modeless HTTP connections. Hope the four emails I sent in response (5 January 2016), went some way to satisfying the concerns expressed. Here is a list of the issues discussed, in the dialog mentioned above: 1. "Session" defined; 2. Avoid row DELETEs; 3. Periodically TRUNCATE each table in a pool of session context tables; 4. Embed a session ID key parameter in an HTML "hidden" field (optional); 5. Use sequence generators as rapid global iterators controlling access to session context tables;
<SNIP>
Thanks to forum members for taking the time to read my email.
This feels hugely overcomplicated. I also didn't read most of the last thread, so forgive me if you've answered this already: How many website requests a second (that actually need to touch session data) are you expecting? How much space is the session data going to take? (like, 5 Gig a day?) If its a huge number, you should put effort into growing horizontally, not all of this stuff. If its a small number, you'll spend more time fixing all the broken things than its worth. Have you benchmarked this? In my mind, complicated == slow. Sorry if I'm raining on your parade, it looks like you have really put a lot of work into this. Have you considered saving session data to disk is faster than saving to db? A good reverse web proxy can stick a session to the same backend. 1 web proxy up front, 5 web servers behind it. I'd bet its way faster. -Andy -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
