I used tdengine for a few weeks, since our table have more than 30 million record for a table, however I want to filter with a nchar column. I have built a cluster with three nodes. But the filter response speed is not as fast as MySQL.I thought that if I can create index on this column the speed will be faster. Since i filtered with timestamp which is the primary key and tdengine automatically create index on this column. So I want to ask if tdengine supports create index ? If so, how to create? Can some help?
TDengine not support create index on other columns till now.BUt it automatically create index for ts(the first column timestamp type). It will support create index on normal column in the furture.
Related
I have a table in snowflake with around 1000 columns, i have an id column which is of integer type
when i run query like
select * from table where id=12
it is scanning all the micro-paritions .I am expecting that snowflake will maintain metadata of min/max of id column and based on that it should scan only one partition rather than all the partition.
In this doc https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html its mentioned that they maintain min/max , disticnt value of columns in each micro-partition.
How can i take advantage of partititon pruning in this scenario?Currently even for unique id snowflake is scanning all the partitions.
It's a little more complicated than that unfortunately. Snowflake would only scan a single partition if your table was perfectly clustered by your id column, which it probably isn't, nor should it be. Snowflake is a data warehouse and isn't ideal for single-row lookups.
You could always cluster your table by your id column but you usually don't want to do this in a data warehouse. I would recommend reading this document to understand how table clustering works.
Does TDengine support index on a normal table column? I know TDengine has a timestamp index for the first column. I want to filter according to a normal table column efficiently. Can I add an index on that column?
I think TDengine doesn't support index in 2.x versions. In later versions maybe inverted index will be added like ES.
I just created a table with TWO primary keys in SQL Server. One column is age, another is ID number and I set the option to CLUSTER INDEX, so it automatically creates a cluster index on both columns. However, when I query the table, the results only seem to sort the ID and completely disregard/ignore the AGE (other PK and other Cluster index column). Why is this? Why is it only sorting based on the first cluster index column?
The query optimizer may decide to use the physical ordering of the rows in the table if there is no advantage in ordering any other way. So, when you select from the table using a simple query, it may be ordered this way. It is very easy to assume that the rows are physically stored in the order specified within the definition of your clustered index. But this turns out to be a false assumption.
Please view the following article for more details: Clustered Index do “NOT” guarantee Physically Ordering or Sorting of Rows
Lets say that a column will only be used for joining. (i.e. I won't be ordering on the column, nor will a search for specific values in the column individually) ... the only thing that I will use the column for is joining to another table.
If the database supports Hash Joins (which from my understanding don't benefit from indexes) .. then wouldn't the addition of an index be completely redundant? (and wasteful) ?
In SQL Server it will still prevent a Key Lookup.
If you JOIN on an unindexed field, the server needs to get the values for that field from the clustered index.
If you JOIN on a NC index, the values can be obtained directly without loading all the data pages from the cluster (which really is the whole table).
So essentially you save yourself a lot of IO as the first step filters down based on a very narrow index instead of on the entire table loaded from disk.
I have a table with several indexes. All of them contain an specific integer column.
I'm moving to mysql 5.1 and about to partition the table by this column.
Do I still have to keep this column as key in my indexes or I can remove it since partitioning will take care of searching only in the relevant keys data efficiently without need to specify it as key?
Partition field must be part of index so the answer is that I kave to keep the partitioning column in my index.
Partitioning will only slice the values/ranges of that index into separate partitions according to how you set it up. You'd still want to have indexes on that column so the index can be used after partition pruning has been done.
Keep in mind there's a big impact on how many partitions you can have, if you have an integer column with only 4 distinct values in it, you might create 4 partitions, and an index would likely not benefit you much depending on your queries.
If you got 10000 distinct values in your integer column, you hit system limits if you try to create 10k partitions - you'll have to partition on large ranges (e.g. 0-1000,1001-2000, etc.) in such a case you'll benefit from an index (again depending on how you query the tables)