On Thu, Nov 17, 2016 at 3:55 AM, Metatrader EA wrote:
> How can I check this?
Several options are listed in the docs:
https://www.postgresql.org/docs/9.6/static/monitoring.html
--
Michael
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your sub
On Thu, Nov 17, 2016 at 9:36 AM, Rick Otten
wrote:
>
> Does it matter if I also try to CLUSTER the materialized view on that
> primary sort field? Or is it already clustered because of the 'order by'?
>
> [...]
>
> When I refresh the materialized view (concurrently) is the order_by
> preserved?
If I construct the materialized view with an 'order by', I can use a BRIN
index to a sometimes significant performance advantage, at least for the
primary sort field. I have observed that even though the first pass is a
little lossy and I get index rechecks, it is still much faster than a
regular
After Jeff Janes' reply, I have tried a couple of limit values and found at
the current state of data, 90 was a change on the query planner.
explain (analyze, buffers)
select booking0_.*
from booking booking0_
where (booking0_.customer_id in (select customer1_.id from
customer cust
Hi,
How can I check this?
//Bill
On Thu, Nov 17, 2016 at 12:02 PM, Guillaume Cottenceau wrote:
> Locks? (VACUUM FULL, etc) Autovacuum?
>
> > Hi,
> >
> > I run this query select count(*) from analyse_forecast where
> daterange_analyse
> > <@ daterange( current_date - 150, current_date, '[]') ;
Locks? (VACUUM FULL, etc) Autovacuum?
> Hi,
>
> I run this query select count(*) from analyse_forecast where
> daterange_analyse
> <@ daterange( current_date - 150, current_date, '[]') ;
>
> Sometimes will query be quick and sometimes is same query SUPER SLO
>
> Something I can do ? Somethin
Hi,
I run this query select count(*) from analyse_forecast where
daterange_analyse <@ daterange( current_date - 150, current_date, '[]') ;
Sometimes will query be quick and sometimes is same query SUPER SLO
Something I can do ? Something I can check for ?
//Bill
