Re: Gained %20 performance after disabling bitmapscan

2018-10-26 Thread Jeff Janes
On Mon, Oct 22, 2018 at 3:20 AM Yavuz Selim Sertoglu < yavuzselim.serto...@medyasoft.com.tr> wrote: > Thanks for the reply Jeff, > > I know 20ms is nothing but it shows me that there is a problem with my > configuration. I want to find it. > This is a dangerous assumption. This is no configurati

Ynt: Gained %20 performance after disabling bitmapscan

2018-10-22 Thread Yavuz Selim Sertoglu
(actual time=0.001..0.796 rows=12768 loops=1) Planning time: 0.909 ms Execution time: 85.839 ms shared_buffers is 256G effective_cache_size is 768G Database size about 90G Gönderen: Jeff Janes Gönderildi: 19 Ekim 2018 Cuma 22:40:57 Kime: Yavuz Selim Sertoglu B

Ynt: Gained %20 performance after disabling bitmapscan

2018-10-21 Thread Yavuz Selim Sertoglu
mance@lists.postgresql.org Konu: Re: Gained %20 performance after disabling bitmapscan Yavuz, cannot add much to other points but as for index-only scan, an (auto)vacuum must be run in order to optimizer understand it can utilize index-only scan. Please check if autovacuum was run on the table after index creatio

Ynt: Gained %20 performance after disabling bitmapscan

2018-10-21 Thread Yavuz Selim Sertoglu
i: pgsql-performance@lists.postgresql.org Konu: Re: Gained %20 performance after disabling bitmapscan Yavuz Selim Sertoglu writes: > I have a problem with my query. Query always using parallel bitmap heap scan. Have you messed with the parallel cost parameters? It seems a bit surprising that this query wants to

Re: Gained %20 performance after disabling bitmapscan

2018-10-19 Thread Jeff Janes
On Fri, Oct 19, 2018 at 3:19 AM Yavuz Selim Sertoglu < yavuzselim.serto...@medyasoft.com.tr> wrote: > Hi all, > > I have a problem with my query. Query always using parallel bitmap heap > scan. I've created an index with all where conditions and id but query does > not this index and continue to u

Re: Gained %20 performance after disabling bitmapscan

2018-10-19 Thread Vladimir Ryabtsev
Yavuz, cannot add much to other points but as for index-only scan, an (auto)vacuum must be run in order to optimizer understand it can utilize index-only scan. Please check if autovacuum was run on the table after index creation and if no, run it manually. Vlad

Re: Gained %20 performance after disabling bitmapscan

2018-10-19 Thread Tom Lane
Yavuz Selim Sertoglu writes: > I have a problem with my query. Query always using parallel bitmap heap scan. Have you messed with the parallel cost parameters? It seems a bit surprising that this query wants to use parallelism at all. > Index Cond: (((mukellef_id)::text = '0123456789'::

Re: Gained %20 performance after disabling bitmapscan

2018-10-19 Thread Justin Pryzby
On Fri, Oct 19, 2018 at 07:19:12AM +, Yavuz Selim Sertoglu wrote: > I have a problem with my query. Query always using parallel bitmap heap scan. > I've created an index with all where conditions and id but query does not > this index and continue to use bitmapscan. So I decided disable bitma

Gained %20 performance after disabling bitmapscan

2018-10-19 Thread Yavuz Selim Sertoglu
Hi all, I have a problem with my query. Query always using parallel bitmap heap scan. I've created an index with all where conditions and id but query does not this index and continue to use bitmapscan. So I decided disable bitmap scan for testing. And after that, things became strange. Cost is