[GRASS-user] the performance of displaying vector attributes - with MySQL no difference!!

Jarosław Jasiewicz jarekj at amu.edu.pl
Tue Nov 14 08:00:53 EST 2006


Zbigniew Perski napisał(a):

>On Tue, 2006-11-14 at 10:57 +0100, Zbigniew Perski wrote:
>  
>
>>On Mon, 2006-11-13 at 19:52 +0100, Jarek Jasiewicz wrote:
>>    
>>
>>>>Hi again,
>>>>the problem of my database is that I don't see any way to optimize it.
>>>>Imagine if you have 20 thousands of xyz points and want just to
>>>>visualize them in different colors (dem-like color scale). Each point
>>>>has its unique x,y,z values...
>>>>I tried to assign indexes for my "z" column using:
>>>> 
>>>>	ALTER TABLE my_points ADD INDEX(z_ccordinate);
>>>>
>>>>And I don't see any difference in performance with e.g. v.univar.sh 
>>>>So maybe I am doing something wrong?
>>>>  
>>>>        
>>>>
>>>If I understood well from the previous post threre is a RGB column it is 
>>>indexed? how much categories of rgb colors you have. If you have as many 
>>>categories as values this is the problem. In grass, graphical engine 
>>>must assing color and render every pixel individualy
>>>
>>>      
>>>
>>Right I have tried both: to index my "z" column and then grassrgb as
>>well. There are 30 categories and I guess it would speed up things.
>>Maybe I was wrong with indexing?
>>
>>    
>>
>
>most probably I am doing somethig wrong with indexing:
>
>mysql> ALTER TABLE PS_points ADD INDEX(grassrgb);
>Query OK, 161884 rows affected (7.96 sec)
>Records: 161884  Duplicates: 0  Warnings: 0
>
>zero duplicates: it is strange because I have 30 categories!
>
>Thanks
>
>Z.
>
>
>  
>
>>Thanks
>>
>>Zbigniew
>>
>>
>>
>>    
>>
It means you have no duplicate records, no categories!




More information about the grass-user mailing list