gold
SELECT id FROM Player_Attributes WHERE preferred_foot = 'right' ORDER BY potential ASC NULLS LAST LIMIT 4
- potential
- ascending
sha256:ee3eddd7b62571d278bf94c51013b6dcc2abc28baea5ce673e2542e005e14c81
R-ORD GOLD-ONLY not-a-function-of-the-data
european_football_2 · mini_dev_postgresql from https://bird-bench.oss-cn-beijing.aliyuncs.com/minidev.zip (sha256 cc48ba16838204e4e214512030cb572eeb5f7bcdd999bae4b9b6ff12ec13b92f, downloaded 2026-09-07), member minidev/MINIDEV/mini_dev_postgresql.json
Please provide top four football players' IDs who are among the lowest potential players and prefer to use the right foot when attacking.
the hint the set supplies: lowest potential players refers to MIN(potential); prefer to use the right foot when attacking refers to preferred_foot = 'right'
This question was audited without a prediction beside it, so there is nothing to compare the gold with. The probes below read the gold alone.
SELECT id FROM Player_Attributes WHERE preferred_foot = 'right' ORDER BY potential ASC NULLS LAST LIMIT 4
sha256:ee3eddd7b62571d278bf94c51013b6dcc2abc28baea5ce673e2542e005e14c81
from evidence-gold.json, 4 rows
| idint8 |
|---|
| 132236 |
| 132235 |
| 66213 |
| 66214 |
A smell is a mechanical reason to read this gold statement again. It is a heuristic: it does not state that the statement is wrong, and a maintainer decides.
this statement orders by a text column holding only numbers, and ordering it as a number gives a different answer, so the gold may be sorting 9.5 above 10
no ORDER BY key resolves to a text column
{
"heuristic": true,
"reason": "no ORDER BY key resolves to a text column",
"keys": [
{
"key": "potential",
"column": "player_attributes.potential",
"declared_type": "bigint",
"not_applicable": "the column is not declared as text"
}
]
}
this statement cuts its result at a LIMIT that does not decide which rows come back, so a different but equally correct statement can return other rows and score zero
{
"heuristic": true,
"cut": 4,
"offset": 0,
"distinct_kept": false,
"unbounded_sql": "SELECT id, potential AS attestql_ordering_key_0 FROM player_attributes WHERE preferred_foot = 'right' ORDER BY potential ASC NULLS LAST",
"unbounded_rows": 138409,
"projected_columns": [
"id"
],
"ordering_key_columns": [
"attestql_ordering_key_0"
],
"ordering_keys": [
{
"key": "potential",
"direction": "asc",
"nulls": "last",
"nulls_first_in_effect": false,
"returned_rows_null_in_this_key": 0,
"fires": false
}
],
"case": null
}
rerun over the same rows in another physical order this statement gives another answer, so its result depends on how the rows are stored and not only on the data
from smells.json, 4 rows
| 132235 |
| 132236 |
| 66213 |
| 66214 |
{
"heuristic": true,
"rule": "R-ORD",
"baseline_result_hash": "sha256:ee3eddd7b62571d278bf94c51013b6dcc2abc28baea5ce673e2542e005e14c81",
"baseline_result": {
"columns": [
{
"name": "id",
"declared_type": "int8"
}
],
"row_count": 4,
"truncated": false,
"rows_shown": 4,
"rows": [
[
{
"type": "int",
"value": 132236
}
],
[
{
"type": "int",
"value": 132235
}
],
[
{
"type": "int",
"value": 66213
}
],
[
{
"type": "int",
"value": 66214
}
]
],
"result_hash": "sha256:ee3eddd7b62571d278bf94c51013b6dcc2abc28baea5ce673e2542e005e14c81"
},
"planner_statistics": {
"player_attributes": {
"last_analyze": "2026-09-14 12:51:04.620709+00",
"last_autoanalyze": null,
"n_mod_since_analyze": 0
}
},
"shuffle": {
"seed": "1",
"row_limit": 300000,
"tables": [
"player_attributes"
],
"tables_not_shuffled": [],
"tables_skipped_for_size": {
"laptimes": 400524,
"legalities": 427907,
"posthistory": 303155,
"trans": 1056320,
"yearmonth": 383282
},
"tables_not_reached_by_a_copy": {}
},
"shuffled_copies": {
"run": true,
"verdict": "not_equal",
"differs": true,
"result_hash": "sha256:6af84bd25662febc482a0ba30702d375316d9cf74cbcebc3cb6602719ab67791",
"result": {
"columns": [
{
"name": "id",
"declared_type": "int8"
}
],
"row_count": 4,
"truncated": false,
"rows_shown": 4,
"rows": [
[
{
"type": "int",
"value": 132235
}
],
[
{
"type": "int",
"value": 132236
}
],
[
{
"type": "int",
"value": 66213
}
],
[
{
"type": "int",
"value": 66214
}
]
],
"result_hash": "sha256:6af84bd25662febc482a0ba30702d375316d9cf74cbcebc3cb6602719ab67791"
}
},
"plan_variant": {
"run": false,
"reason": "the plan variant was not asked for"
}
}
this statement returns the same whole row more than once and never says DISTINCT, so a statement answering the same question once per row disagrees on multiplicity alone
{
"heuristic": true,
"rows": 4,
"distinct_rows": 4,
"repeated_rows": 0,
"largest_repeat": 1,
"result_bounded": false,
"distinct_stated": false,
"set_operation": false
}
SELECT id FROM Player_Attributes WHERE preferred_foot = 'right' ORDER BY potential ASC NULLS LAST LIMIT 4
result_hash sha256:ee3eddd7b62571d278bf94c51013b6dcc2abc28baea5ce673e2542e005e14c81 recomputed from this JSON: match
record_hash sha256:c02b421d12b14794155fb2960b799f3b878774d1591e0736fcda0188635e92b6 recomputed from this JSON: match
from evidence-gold.json, 4 rows
| idint8 |
|---|
| 132236 |
| 132235 |
| 66213 |
| 66214 |
re-run this statement read-only against PostgreSQL 16.15 (Debian 16.15-1.pgdg13+2) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit | server=172.17.0.2/32:5432 | database=bird under the session settings and over the data this record's fixture digest names, and compare the two results under R-ORD