[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