Bug description
I am adding a value range filter to my dashboard.
The data set I am applying it to is pulled from a postgreSQL query.
It has a column we'll call numerical_data, it is of type decimal.
numerical_data currently has values between 0.03 and 1.08 and some NULL values. One important detail, it only has one value above 1, which is 1.08, all others are below 1.
When i add the value range filter, it only allows me to filter between 0 and 1, only giving me the option to choose 0 or 1. What I expect is to have granular filtering from the minimum of my dataset to the maximum. Here it seems to be rounding the decimal to an integer and giving me only these options.
I did a bit of tests and I am able to counter this behaviour and have proper filtering if I:
- Filter the initial data set to only give me values below 1
- Add a pre-filter on the filter itself again giving me only values below 1 (I guess this is the same as the previous option).
I am not sure if this might be correlated to #33206 .
I also modified the data to check some other conditions: When my data is spread between 0.03 and 2.16, with multiple values between 1 and 2, I get: - When left as is, integer only filtering with options: 0, 1 and 2 - When pre filtered for only values below 2: integer filtering with options 0 and 1 - When pre filtered for only values below 1: decimal filtering
Screenshots/recordings
No response
Superset version
5.0.0
Python version
3.9
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
This is a known limitation in Superset's Value Range filter: the slider component defaults to integer steps unless a 'step' configuration is provided, so for decimal columns, only integer options are selectable. This isn't caused by rounding in the backend or frontend logic, but rather by the missing step configuration in the filter UI. Your workaround—pre-filtering to restrict the range to decimals—matches what others have found effective.
This behavior is related to issue #33206, which describes inconsistent filtering for numeric values with different decimal precision, especially when integer values are selected first. The issue affects multiple databases, including PostgreSQL.
A suggested workaround is to create a new column in your dataset SQL that scales decimal values (for example, multiplying by 100), then use this new column for filtering, which allows for more granular control over the range. There are currently no recent pull requests addressing this limitation, so it's a missing feature rather than a regression or bug in rounding logic.
If you have logs or stacktraces, feel free to share them—I'm happy to help interpret if needed.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: rusackas
Very much open to a PR for this. Seems like something AI could take a crack at :)