Re: select count(*) is slow

Поиск
Список
Период
Сортировка
От aditya desai
Тема Re: select count(*) is slow
Дата
Msg-id CAN0SRDGOY-0aiMONf_bJ6SuiwQ9C5snTqCxbXs=23NyF0ig8JQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: select count(*) is slow  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-performance
Thanks to all of you. Removed casting to numeric from Index. Performance improved from 12 sec to 500 ms. Rocket!!!

On Tue, Apr 6, 2021 at 9:14 PM Andrew Dunstan <andrew@dunslane.net> wrote:

On 4/6/21 9:30 AM, aditya desai wrote:
> Thanks Tom. Will try with numeric. Please ignore table and index naming.
>
> On Tue, Apr 6, 2021 at 6:55 PM Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>     aditya desai <admad123@gmail.com <mailto:admad123@gmail.com>> writes:
>     > Below query takes 12 seconds. We have an index on  postcode.
>
>     > select count(*) from table where postcode >= '00420' AND
>     postcode <= '00500'
>
>     That query does not match this index:
>
>     > CREATE INDEX Table_i1
>     >     ON table  USING btree
>     >     ((postcode::numeric));
>
>     You could either change postcode to numeric, change all your queries
>     of this sort to include the cast explicitly, or make an index that
>     doesn't have a cast.
>
>                           
>


IMNSHO postcodes, zip codes, telephone numbers and the like should never
be numeric under any circumstances. This isn't numeric data (what is the
average postcode?), it's textual data consisting of digits, so they
should always be text/varchar. The index here should just be on the
plain text column, not cast to numeric.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
Следующее
От: Szalontai Zoltán
Дата:
Сообщение: procedure using CURSOR to insert is extremely slow