Re: SELECT performance drop

With Pascal's suggestion, I added a new index: CREATE INDEX fm_order_sid_type_idx ON fm_order (session_id, type); which improved the query to 2mS! https://explain.depesz.com/s/oxvs Thank you, Pascal! On Thu, Jan 24, 2019 at 9:52 AM Jan Nielsen wrote: > > > On Wed, Jan

Re: SELECT performance drop

On Wed, Jan 23, 2019 at 12:37 PM legrand legrand < [email protected]> wrote: > Hi, > is there an index on > fm_order(session_id,type)? > There isn't at the moment: table_name | index_name | column_name +--+

Re: SELECT performance drop

On Wed, Jan 23, 2019 at 6:51 AM Jim Finnerty wrote: > One thing that isn't helping is that you have a redundant predicate. The > selectivity of this predicate is also estimated too low, so removing the > redundant predicate might improve the estimate and change the plan: > > (

Re: SELECT performance drop

On Tue, Jan 22, 2019 at 2:55 PM legrand legrand wrote: > Hello, > could you check that statistics for fm_session are accurate ? > > Regards > PAscal > heroku pg:psql -c "SELECT schemaname, relname, last_analyze FROM pg_stat_all_tables WHERE relname LIKE 'fm_%'" schemaname |relname | last

Re: SELECT performance drop

On Tue, Jan 22, 2019 at 1:04 PM Jan Nielsen wrote: > I just notice that one of my Hibernate JPA SELECTs against my Heroku PG > 10.4 instance is taking a l o o o g to complete > <https://explain.depesz.com/s/r2GU> as this EXPLAIN (ANALYZE, BUFFERS) > shows. The database is 5

SELECT performance drop

I just notice that one of my Hibernate JPA SELECTs against my Heroku PG 10.4 instance is taking a l o o o g to complete as this EXPLAIN (ANALYZE, BUFFERS) shows. The database is 591MB running in PG 10.4 on Heroku with the following row counts and index use: