On Tue, 11 Sep 2001, Stephan Szabo wrote:
> Well, the index isn't used because it estimates (apparently
> correctly) that not using it is cheaper. Because the information about
> whether a row is valid is kept in the heap, for each index hit, the
> heap needs to be read to see if the row is visible. This results in
> jumping about the heap file with seeks and such plus the index
> search itself. When most of the rows are going to be returned, the
> sequence scan will generally be cheaper.
It would me drive crazy if this "cheaper" solution would last miore than
30 seconds for PostgreSQL if MS-SQL server solves this tasks in less
than a second. This would really destroy all my plans with PostgreSQL
if it would be true (what I can´t really imagine).
> Alot of the real time may be being spent in the sort step. You may want
> to raise the amount of memory used for sorting and see if that helps.
How to raise this memory amount.
This is more or less a theoretical question because sorting of about
150 items can´t last 30s. The result set is:
MeldeKategorie Anz
ADV 142
BOR 1
BRU 10
CAM 34965
CHL 45
CJK 61
CLO 6
COX 237
CRY 645
ECH 269
ECO 3030
EHC 750
FRT 1
FSV 160
GIL 3013
HAV 1495
HBV 3352
HCV 7710
HDV 18
HEV 33
HFA 24
HIN 66
HIV 3628
HTV 132
HXV 3
INV 2400
LEG 203
LEP 17
LIS 167
MSV 5164
MYL 2
MYT 4650
NEI 576
NWV 6566
PLA 692
POV 4
RBV 1
RIC 2
RTV 42862
RUB 1
SAL 47829
SHI 917
SPA 33
STY 60
TOX 26
TRI 6
TRP 674
VCH 2
YEN 4810
There is not much to sort here, thought.
Kind regards
Andreas.