Re: [PERFORM] Query regarding EXPLAIN (ANALYZE,BUFFERS)

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [PERFORM] Query regarding EXPLAIN (ANALYZE,BUFFERS)
Дата
Msg-id CAFj8pRBJtUhQJ7XFDDULXDTbiw4G+3Z1J27LW7PmVb3GnN+DJQ@mail.gmail.com
обсуждение исходный текст
Ответ на [PERFORM] Query regarding EXPLAIN (ANALYZE,BUFFERS)  (Subramaniam C <subramaniam31784@gmail.com>)
Список pgsql-performance


2017-09-21 12:52 GMT+02:00 Subramaniam C <subramaniam31784@gmail.com>:
Hi

I wanted to query top 20 rows by joining two tables, one table having around 1 lac rows and other table having 5 lac rows. Since I am using ORDER BY in the query so I created compound index with the columns being used in ORDER BY. Initially index size was  939 MB.

Then I ran EXPLAIN(ANALYZE,BUFFERS) for this query which took around 20 secs as it was not using the compound index for this query. So I drop this index and created again. The index size now got reduced to 559 MB.

After this if I ran the EXPLAIN(ANALYZE,BUFFERS) for this query it was using the index and took only 5 secs.

Can you please explain how the index size got reduced after recreating it and how the query started using the index after recreating?


The index can be bloated - when you recreate it or when you use REINDEX command, then you remove a bloat content. VACUUM FULL recreate indexes too.

Fresh index needs less space on disc (the read is faster), in memory too and has better structure - a access should be faster.

 
Thanks and Regards
Subramaniam

В списке pgsql-performance по дате отправления:

Предыдущее
От: Subramaniam C
Дата:
Сообщение: [PERFORM] Query regarding EXPLAIN (ANALYZE,BUFFERS)
Следующее
От: Tobias Gierke
Дата:
Сообщение: [PERFORM] Parallel sequential scan not supported for stored procedure withRETURN QUERY EXECUTE ?