Re: Watching for view changes

2018-12-22 Thread Mitar
Hi! This is of very practical concern. :-) I have many apps I developed in Meteor [1] using MongoDB. The whole Meteor stack is about reactive programming where web UI automatically rerenders as data in the database is changing. Meteor achieves this using complicated server-side code which tails Mo

Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2

2018-12-22 Thread Jeff Janes
> > > - Does the analyse output below mean that it only scanned 51538 of 65463 > rows in the table? Is school_id 36 just being missed in the sample? (This > happens when the analyse is repeated ) > Is there a transaction which had deleted all of school_id=36, and then was just left open indefinite

Re: Watching for view changes

2018-12-22 Thread Rob Sargent
Is this of theoretical interest (up to and including a specification/requirement) or this a practical concern (i.e. need to know when to update somebody’s dashboard widget (but the query is too slow to simply refresh on-demand)? > On Dec 22, 2018, at 9:42 AM, Ricardo Martin Gomez > wrote: >

Re: Watching for view changes

2018-12-22 Thread Ricardo Martin Gomez
Hi, perhaps you can use triggers for some tables. Regards. Obtener Outlook para Android From: Mitar Sent: Saturday, December 22, 2018 1:21:49 AM To: Kevin Brannen Cc: pgsql-general@lists.postgresql.org Subject: Re: Watching for view changes

Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2

2018-12-22 Thread Mark
Hi Virendra, Thanks for the reply. You must have missed it, but I've already done that (see my original email). The stats target for that column is already set to 1. db=> SELECT attstattarget FROM pg_attribute WHERE attrelid = 'public.common_student'::regclass AND attname = 'school_id'; att