From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Subramaniam C <subramaniam31784(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query regarding EXPLAIN (ANALYZE,BUFFERS) |
Date: | 2017-09-21 18:37:34 |
Message-ID: | CAFj8pRBJtUhQJ7XFDDULXDTbiw4G+3Z1J27LW7PmVb3GnN+DJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2017-09-21 12:52 GMT+02:00 Subramaniam C <subramaniam31784(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Gierke | 2017-09-25 11:10:56 | Parallel sequential scan not supported for stored procedure with RETURN QUERY EXECUTE ? |
Previous Message | Subramaniam C | 2017-09-21 10:52:11 | Query regarding EXPLAIN (ANALYZE,BUFFERS) |