Re: [PERFORM] Speeding up JSON + TSQUERY + GIN

2017-03-06 Thread Sven R. Kunze
On 06.03.2017 05:25, Jeff Janes wrote: Bitmaps can overflow and drop the row-level information, tracking only the blocks which need to be inspected. So it has to have a recheck in case that happens (although in your case it is not actually overflowing--but it still needs to be prepared for tha

Re: [PERFORM] Huge difference between ASC and DESC ordering

2017-03-06 Thread Jeff Janes
On Mon, Mar 6, 2017 at 8:46 AM, twoflower wrote: > Thank you Jeff. > > There are 7 million rows satisfying fk_id_client = 20045. There is an > index on fk_id_client, now I added a composite (fk_id_client, id) index but > that did not help. > With 7 million rows, you shouldn't expect any magic he

Re: [PERFORM] Huge difference between ASC and DESC ordering

2017-03-06 Thread twoflower
Thank you Jeff. There are 7 million rows satisfying fk_id_client = 20045. There is an index on fk_id_client, now I added a composite (fk_id_client, id) index but that did not help. I see the point of what you are saying, but still don't understand how these two situations (*asc* vs. *desc*) are n

Re: [PERFORM] Huge difference between ASC and DESC ordering

2017-03-06 Thread Jeff Janes
On Mon, Mar 6, 2017 at 6:22 AM, twoflower wrote: > I have the following query > > select * > from "JOB_MEMORY_STORAGE" st > inner join "JOB_MEMORY" s on s.fk_id_storage = st.id > where st.fk_id_client = 20045 > order by s.id asc limit 50 > > The query stops as soon as it finds 50 rows which mee

[PERFORM] Huge difference between ASC and DESC ordering

2017-03-06 Thread twoflower
I have the following query which takes 90 seconds to finish. *JOB_MEMORY* has 45 million rows, *JOB_MEMORY_STORAGE* has 50 000 rows. Query plan: As you can see, it is indeed using an index *JOB_MEMORY_id_desc* in a backward direction, but it is very slow. When I change ordering to *desc* in the

[PERFORM] Performance issue after upgrading from 9.4 to 9.6

2017-03-06 Thread Piotr Gasidło
We are having some performance issues after we upgraded to newest version of PostgreSQL, before it everything was fast and smooth. Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we upgraded to 9.6.2 with no improvement. Some information about our setup: Freebsd, Solaris (SmartOS),

Re: [PERFORM] Performance issue in PostgreSQL server...

2017-03-06 Thread Dinesh Chandra 12108
Dear Justin, Below is the output of Query SELECT * FROM pg_stats WHERE tablename='point' AND attname='domain_class_id' ; schemaname | tablename | attname | inherited | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation "evidence