Re: indices - used by which user ?

Поиск
Список
Период
Сортировка
От
Тема Re: indices - used by which user ?
Дата
Msg-id 22017.213.33.72.146.1052392607.squirrel@webmail.inode.at
обсуждение исходный текст
Ответ на Re: indices - used by which user ?  (Manfred Koizar <mkoi-pg@aon.at>)
Ответы Re: indices - used by which user ?  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Список pgsql-general
> On Thu, 8 May 2003 09:20:31 +0200 (CEST), <g.hintermayer@inode.at>
> wrote:
>>So that's a factor of about 10 faster, only by changing the user, very
>> strange.
>
> Very, very strange!  Compare the outputs of SHOW ALL for both cases. If
> there are any differences, please inform us.
>
>>         ->  Seq Scan on produkt  (cost=0.00..2417.41 rows=2141
>> width=40)
>                                                ^^^^         ^^^^
>>                                  (actual time=0.02..27.12 rows=2141
>> loops=1)
>
> Unless I'm missing something, your produkt table has more pages than
> tuples.  VACUUM FULL should reduce its size to ca. 22 pages.
>
Could be, I'm running VACUUM only once a week.

Well the whole problem seems to be because of different types of the
joined columns.
I rebuilt my database to have the same datatype on the joined columns
(both character varying(10 now, before one text, one character
varying(10)) and my query works as fast as in the other databases.

Somebody shall correct me if I'm wrong, but that's what I found out:

The optimizer *never* uses an index when doing NATURAL INNER JOIN when the
joined rows have the same data type (at least I could'nt find a case where
he does) regardless if ther's an index on the joined column in one or both
tables or not.
If the joined rows have different datatypes (which should'nt be the normal
case) he sometimes does and sometimes doesn't. The slowdown og these joins
seems to be the type cast (character varying to text) and not the unused
index.

Gerhard


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

Предыдущее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: Disk usage
Следующее
От: Erik Ronström
Дата:
Сообщение: Re: Problems upgrading from 7.2.1 to 7.2.4