Re: performance on selecting a row in large tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

  You are right, this query is not the right approach for performance
testing. I thought that this will give an indication about the
performance of a select statement on that table.

  One of those slow queries are running on col02 which has a btree
index. But I use the 'in' expression to get a set of matching rows:

  select * from table where col02 in ('...',[...],'...') 

  This query gets sometimes really slow, I guess it depends on the size
of the set used by 'in'.

  Would the query perform better when I cluster the index on col02 and
force to order the set for the in clause?

  Is there a way to disable the caching for testing? Once I ran the
query, the result set seems to be cached and the second run of the query
is fast. This makes a testing a little difficult ;-)

regards.
Rainer

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux