Re: Not using index

From: Daniele Orlandi <daniele(at)orlandi(dot)com>
To:
Cc: psql-hackers <hackers(at)postgreSQL(dot)org>
Subject: Re: Not using index
Date: 2000-05-11 01:09:20
Message-ID: 391A0840.F02504C1@orlandi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> There is certainly not a dependence on * as such.

Yes, that was pretty strange, but, not knowing the internals of the
optimizer, I wondered why a change in the target list could have changed
the decision of the optimizer.

> However, the estimated row width does affect the cost estimate for operations
> like SORT, where we have to guess how many rows will fit in memory. It looks
> to me like your example case is right near the boundary where the system
> thinks that index scan and sort are of roughly equal cost, so relatively
> small changes will push the choice in one direction or the other.

Yes this is what's happening. I progressively adding attributes to the
targets list and, at some point, the optimizer choosed the other
alternative.

> I'm assuming that you are complaining because one or the other of
> these plans is actually much cheaper than the other in your example.

Yes, more than 12:1 ratio.

> You have, however, carefully refrained from giving us any hint which.
> Care to fess up with more details?

Yes, of course, I hope the following statistics can help you :

This one is the result of vacuum on the table:

NOTICE: Pages 688: Changed 0, reaped 0, Empty 0, New 0; Tup 39100: Vac
0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 100, MaxLen 201; Re-using:
Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.04s/3.37u sec.
NOTICE: Index telecom_settore: Pages 145; Tuples 39100. CPU 0.01s/0.07u
sec.
NOTICE: Index telecom_distretto: Pages 156; Tuples 39100. CPU
0.01s/0.06u sec.
NOTICE: Index telecom_regione: Pages 136; Tuples 39100. CPU 0.01s/0.06u
sec.

This one is with the index:
! system usage stats:
! 0.909758 elapsed 0.830000 user 0.050000 system sec
! [0.870000 user 0.060000 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 282/14 [429/279] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [0/0] voluntary/involuntary context switches
! postgres usage stats:
! Shared blocks: 845 read, 0 written, buffer hit rate =
97.86%
! Local blocks: 0 read, 0 written, buffer hit rate =
0.00%
! Direct blocks: 0 read, 0 written

This one is without the index:
! system usage stats:
! 12.529637 elapsed 12.360000 user 0.150000 system sec
! [12.380000 user 0.190000 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 508/360 [695/657] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [0/0] voluntary/involuntary context switches
! postgres usage stats:
! Shared blocks: 688 read, 1 written, buffer hit rate =
0.72%
! Local blocks: 0 read, 0 written, buffer hit rate =
0.00%
! Direct blocks: 0 read, 0 written

If you need other statistics/tests, just ask and I will be happy to help
you.

Bye!

--
Daniele

-------------------------------------------------------------------------------
Daniele Orlandi - Utility Line Italia - http://www.orlandi.com
Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-05-11 01:42:26 Now 376175 lines of code
Previous Message Tatsuo Ishii 2000-05-11 01:07:19 Re: Multibyte still broken