You have 126 million rows in that table. It's going to take more than a second on a single dc1.large node.

Here's some ways you could improve the performance:

More nodes

Spreading data across more nodes allows more parallelization. Each node adds additional processing and storage. Even if your data volume only justifies one node, if you want more performance, add more nodes.

SORTKEY

For the right type of query, the SORTKEY can be the best way to improve query speed. Sorting data on disk allows Redshift to skip over blocks that it knows does not contain relevant data.

For example, your query has WHERE brandID = 3927, so having brandID as the SORTKEY would make this extremely efficient because very few disk blocks would contain data for one brand.

Interleaved sorting is rarely the best sorting method to use because it is less efficient than a single or compound sort key and takes a long time to VACUUM. If the query you have shown is typical of the type of queries you are running, then use a compound sort key of brandId, ti or ti, brandId. It will be much more efficient.

SORTKEYs are typically a date column, since they are often found in a WHERE clause and the table will be automatically sorted if data is always appended in time order.

The Interleaved Sort would be causing Redshift to read many more disk blocks to find your data, thereby significantly increasing query time.

DISTKEY

The DISTKEY should typically be set to the field that is most used in a JOIN statement on the table. This is because data relating to the same DISTKEY value is stored on the same slice. This won't have such a large impact on a single node cluster, but it is still worth getting right.

Again, you have only shown one type of query, so it is hard to recommend a DISTKEY. Based on this query alone, I would recommend DISTKEY EVEN so that all slices participate in the query. (It is also the default DISTKEY if no specific DISTKEY is selected.) Alternatively, set DISTKEY to a field not shown -- but certainly don't use brandId as the DISTKEY otherwise only one slice will participate in the query shown.

VACUUM

VACUUM your tables regularly so that the data is stored in SORTKEY order and deleted data is removed from storage.

Experiment!

Optimal settings depend upon your data and the queries you typically run. Perform some tests to compare SORTKEY and DISTKEY values and choose the settings that perform the best. Then, test again in 3 months to see if your queries or data has changed enough to make other settings more efficient.

The whole idea around Redshift is not to run in a single node. It is actually designed to run in a sharded cluster and it is expected to have very bad numbers within only one node. If you look at the internals you'll see that is actually designed to run on top of a set of nodes, adding an extra layer for the query processing.

If you are already familiar with the basics, you can check the Best practices.

You are asking Redshift to read and sort nearly a billion rows at what looks like 1000 columns wide. This is going to take a minute.

You only want the top 10 ids so you can break this up and do a lot less work. If you have a reasonable idea of what the max id is then you can add a WHERE clause to only read (and sort) rows that are near this value. Your estimate doesn't need to be very close - just get the number of rows down to a million or so :)

Try:

select * from dbname.tablename where id > <some reasonable guess> order by id desc limit 10;

It would be best if your table is sorted by id (and analyzed) to save on the scan step but even if it isn't the sort phase will be less as the data will still be pruned down.

If you have no idea at all what the max id is you can make improvements by having Redshift find the max id in the query. The cost of this is scanning the table twice but the first time it only needs one column (id).

select * 
from dbname.tablename 
where id > (select max(id) from dbname.tablename) - 1000
order by id desc 
limit 10;

In general it is a good idea to reduced data as early as possible in a query when working with large amounts of data.