# Querying by non partition key column, creating an index

**URL:** https://forum.scylladb.com/t/querying-by-non-partition-key-column-creating-an-index/1436
**Category:** ScyllaDB
**Tags:** data-model, secondary-index
**Created:** [March 31, 2024, 8:05am UTC](https://forum.scylladb.com/t/querying-by-non-partition-key-column-creating-an-index/1436 "2024-03-31T08:05:10Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Guy](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/guy/32/9_2.png) [@Guy](https://forum.scylladb.com/u/Guy)
#### Post date: [March 31, 2024, 8:05am UTC](https://forum.scylladb.com/t/querying-by-non-partition-key-column-creating-an-index/1436/1 "2024-03-31T08:05:10Z")

</div>

> [@](#):
>
> [**Originally from the User Slack**](https://scylladb-users.slack.com/)
> 
> ![Benaceur_Ayoub](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/e711b4ff72efa6b12ec1305f6720316ee107540f.jpeg) **@Benaceur\_Ayoub:** I have a table **“stores”** where _ **'id** ’_ is the partition key, but sometimes I want to query by _ **‘city’** _, the problem is each city will contain thousands of stores, so if I create an index on ‘city’ would that would make the partitions large for that index so therefor this is not viable solution. is this correct ?
> 
> ![Felipe_Cardeneti_Mendes](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/233a9d524fbc97e39f08633c16b3dd2575d1d1f4.jpeg) **@Felipe\_Cardeneti\_Mendes:** Correct! Such an index would be large and likely very imbalanced 🙂
> 
> ![Benaceur_Ayoub](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/e711b4ff72efa6b12ec1305f6720316ee107540f.jpeg) **@Benaceur\_Ayoub:** so there is no way I can query by city ?
> 
> ![Felipe_Cardeneti_Mendes](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/233a9d524fbc97e39f08633c16b3dd2575d1d1f4.jpeg) **@Felipe\_Cardeneti\_Mendes:** Well, if the ratio of stores per city is up to a few thousands an index will do just fine. If it gets to hundreds of thousands then it wouldn’t.
> 
> You probably want to make sure you have a StoreByCity kind of table where you add more cardinality with — for example — a zip code range… then you would simply run parallel queries until you walked over all zips for a given city.
> 
> Or just full table scan with Spark if this is adhoc