Postgres: query planner not respecting table inheritance constraint when querying for null
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I'm having an issue with slow queries that is caused by the planner checking every inherited table instead of only the one with the constraint.
I have a table with 0 rows called "search_result". This table has a few inherited tables with different constraints based on the "polarization", where all our data resides. For example:
CREATE TABLE search_result_positive
(
CONSTRAINT search_result_positive_polarization_check CHECK (polarization = (1))
)
INHERITS (search_result);
CREATE TABLE search_result_negative
(
CONSTRAINT search_result_negative_polarization_check CHECK (polarization = (-1))
)
INHERITS (search_result);
CREATE TABLE search_result_unpolarized
(
CONSTRAINT search_result_unpolarized_polarization_check CHECK (polarization IS NULL)
)
INHERITS (search_result);
When I execute a query using "WHERE polarization = 1", for example, the query planner will show that it has only checked the "search_result_positive": table, which is the desired behavior.
However, when the query is "WHERE polarization IS NULL", it'll check every single table, taking an immense amount of time. Here's an example for "search_result_positive":
SELECT "search_result".* FROM "search_result" WHERE (polarization = 1) ORDER BY published_on DESC LIMIT 20;
Limit (cost=0.44..17.65 rows=20 width=2027) (actual time=3.638..3.666 rows=20 loops=1)
-> Merge Append (cost=0.44..249453.67 rows=289872 width=2027) (actual time=3.637..3.663 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.004..0.004 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization = 1)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245830.25 rows=289871 width=2027) (actual time=3.633..3.658 rows=20 loops=1)
Filter: (polarization = 1)
Planning time: 2.640 ms
Execution time: 3.762 ms
And now, this is what happens when we query for null:
SELECT "search_result".* FROM "search_result" WHERE (polarization IS NULL) ORDER BY published_on DESC LIMIT 20;
Limit (cost=1.93..143.83 rows=20 width=1758) (actual time=205790.210..206266.419 rows=20 loops=1)
-> Merge Append (cost=1.93..462744.74 rows=65221 width=1758) (actual time=205790.208..206266.403 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.006..0.006 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan using ix_search_result_hybrid_published_on_desc on search_result_hybrid (cost=0.14..44.44 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_negative_published_on_asc on search_result_negative (cost=0.42..126163.49 rows=1 width=2039) (actual time=44646.431..44646.431 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 174428
-> Index Scan Backward using ix_search_result_neutral_published_on_asc on search_result_neutral (cost=0.42..53749.59 rows=1 width=1996) (actual time=29539.393..29539.393 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 115678
-> Index Scan using ix_search_result_no_apply_published_on_desc on search_result_no_apply (cost=0.14..44.44 rows=1 width=2882) (actual time=0.003..0.003 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245105.57 rows=1 width=2027) (actual time=131590.509..131590.509 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 295475
-> Index Scan using ix_search_result_unpolarized_published_on_desc on search_result_unpolarized (cost=0.29..35643.06 rows=65215 width=1758) (actual time=13.863..490.048 rows=20 loops=1)
Filter: (polarization IS NULL)
Planning time: 1.197 ms
Execution time: 206266.593 ms
This is driving me crazy. I don't understand why every table is being checked instead of only "search_result_unpolarized". This is driving me crazy already. The only other choice I have for this is to rewrite part of our system to query only a specific table instead of letting Postgres decide, which will be a fair amount of work. There must be a better way. Any help or ideas would be greatly appreciated.
We're using Postgres 9.3.19 on Amazon RDS
postgresql optimization execution-plan postgresql-9.3
add a comment |
I'm having an issue with slow queries that is caused by the planner checking every inherited table instead of only the one with the constraint.
I have a table with 0 rows called "search_result". This table has a few inherited tables with different constraints based on the "polarization", where all our data resides. For example:
CREATE TABLE search_result_positive
(
CONSTRAINT search_result_positive_polarization_check CHECK (polarization = (1))
)
INHERITS (search_result);
CREATE TABLE search_result_negative
(
CONSTRAINT search_result_negative_polarization_check CHECK (polarization = (-1))
)
INHERITS (search_result);
CREATE TABLE search_result_unpolarized
(
CONSTRAINT search_result_unpolarized_polarization_check CHECK (polarization IS NULL)
)
INHERITS (search_result);
When I execute a query using "WHERE polarization = 1", for example, the query planner will show that it has only checked the "search_result_positive": table, which is the desired behavior.
However, when the query is "WHERE polarization IS NULL", it'll check every single table, taking an immense amount of time. Here's an example for "search_result_positive":
SELECT "search_result".* FROM "search_result" WHERE (polarization = 1) ORDER BY published_on DESC LIMIT 20;
Limit (cost=0.44..17.65 rows=20 width=2027) (actual time=3.638..3.666 rows=20 loops=1)
-> Merge Append (cost=0.44..249453.67 rows=289872 width=2027) (actual time=3.637..3.663 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.004..0.004 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization = 1)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245830.25 rows=289871 width=2027) (actual time=3.633..3.658 rows=20 loops=1)
Filter: (polarization = 1)
Planning time: 2.640 ms
Execution time: 3.762 ms
And now, this is what happens when we query for null:
SELECT "search_result".* FROM "search_result" WHERE (polarization IS NULL) ORDER BY published_on DESC LIMIT 20;
Limit (cost=1.93..143.83 rows=20 width=1758) (actual time=205790.210..206266.419 rows=20 loops=1)
-> Merge Append (cost=1.93..462744.74 rows=65221 width=1758) (actual time=205790.208..206266.403 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.006..0.006 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan using ix_search_result_hybrid_published_on_desc on search_result_hybrid (cost=0.14..44.44 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_negative_published_on_asc on search_result_negative (cost=0.42..126163.49 rows=1 width=2039) (actual time=44646.431..44646.431 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 174428
-> Index Scan Backward using ix_search_result_neutral_published_on_asc on search_result_neutral (cost=0.42..53749.59 rows=1 width=1996) (actual time=29539.393..29539.393 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 115678
-> Index Scan using ix_search_result_no_apply_published_on_desc on search_result_no_apply (cost=0.14..44.44 rows=1 width=2882) (actual time=0.003..0.003 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245105.57 rows=1 width=2027) (actual time=131590.509..131590.509 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 295475
-> Index Scan using ix_search_result_unpolarized_published_on_desc on search_result_unpolarized (cost=0.29..35643.06 rows=65215 width=1758) (actual time=13.863..490.048 rows=20 loops=1)
Filter: (polarization IS NULL)
Planning time: 1.197 ms
Execution time: 206266.593 ms
This is driving me crazy. I don't understand why every table is being checked instead of only "search_result_unpolarized". This is driving me crazy already. The only other choice I have for this is to rewrite part of our system to query only a specific table instead of letting Postgres decide, which will be a fair amount of work. There must be a better way. Any help or ideas would be greatly appreciated.
We're using Postgres 9.3.19 on Amazon RDS
postgresql optimization execution-plan postgresql-9.3
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
2
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
1
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
1
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint thatcheck (polarization is not null)
but first you need to move null values out of child tables.
– Yavuz Selim
Mar 9 at 21:33
add a comment |
I'm having an issue with slow queries that is caused by the planner checking every inherited table instead of only the one with the constraint.
I have a table with 0 rows called "search_result". This table has a few inherited tables with different constraints based on the "polarization", where all our data resides. For example:
CREATE TABLE search_result_positive
(
CONSTRAINT search_result_positive_polarization_check CHECK (polarization = (1))
)
INHERITS (search_result);
CREATE TABLE search_result_negative
(
CONSTRAINT search_result_negative_polarization_check CHECK (polarization = (-1))
)
INHERITS (search_result);
CREATE TABLE search_result_unpolarized
(
CONSTRAINT search_result_unpolarized_polarization_check CHECK (polarization IS NULL)
)
INHERITS (search_result);
When I execute a query using "WHERE polarization = 1", for example, the query planner will show that it has only checked the "search_result_positive": table, which is the desired behavior.
However, when the query is "WHERE polarization IS NULL", it'll check every single table, taking an immense amount of time. Here's an example for "search_result_positive":
SELECT "search_result".* FROM "search_result" WHERE (polarization = 1) ORDER BY published_on DESC LIMIT 20;
Limit (cost=0.44..17.65 rows=20 width=2027) (actual time=3.638..3.666 rows=20 loops=1)
-> Merge Append (cost=0.44..249453.67 rows=289872 width=2027) (actual time=3.637..3.663 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.004..0.004 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization = 1)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245830.25 rows=289871 width=2027) (actual time=3.633..3.658 rows=20 loops=1)
Filter: (polarization = 1)
Planning time: 2.640 ms
Execution time: 3.762 ms
And now, this is what happens when we query for null:
SELECT "search_result".* FROM "search_result" WHERE (polarization IS NULL) ORDER BY published_on DESC LIMIT 20;
Limit (cost=1.93..143.83 rows=20 width=1758) (actual time=205790.210..206266.419 rows=20 loops=1)
-> Merge Append (cost=1.93..462744.74 rows=65221 width=1758) (actual time=205790.208..206266.403 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.006..0.006 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan using ix_search_result_hybrid_published_on_desc on search_result_hybrid (cost=0.14..44.44 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_negative_published_on_asc on search_result_negative (cost=0.42..126163.49 rows=1 width=2039) (actual time=44646.431..44646.431 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 174428
-> Index Scan Backward using ix_search_result_neutral_published_on_asc on search_result_neutral (cost=0.42..53749.59 rows=1 width=1996) (actual time=29539.393..29539.393 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 115678
-> Index Scan using ix_search_result_no_apply_published_on_desc on search_result_no_apply (cost=0.14..44.44 rows=1 width=2882) (actual time=0.003..0.003 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245105.57 rows=1 width=2027) (actual time=131590.509..131590.509 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 295475
-> Index Scan using ix_search_result_unpolarized_published_on_desc on search_result_unpolarized (cost=0.29..35643.06 rows=65215 width=1758) (actual time=13.863..490.048 rows=20 loops=1)
Filter: (polarization IS NULL)
Planning time: 1.197 ms
Execution time: 206266.593 ms
This is driving me crazy. I don't understand why every table is being checked instead of only "search_result_unpolarized". This is driving me crazy already. The only other choice I have for this is to rewrite part of our system to query only a specific table instead of letting Postgres decide, which will be a fair amount of work. There must be a better way. Any help or ideas would be greatly appreciated.
We're using Postgres 9.3.19 on Amazon RDS
postgresql optimization execution-plan postgresql-9.3
I'm having an issue with slow queries that is caused by the planner checking every inherited table instead of only the one with the constraint.
I have a table with 0 rows called "search_result". This table has a few inherited tables with different constraints based on the "polarization", where all our data resides. For example:
CREATE TABLE search_result_positive
(
CONSTRAINT search_result_positive_polarization_check CHECK (polarization = (1))
)
INHERITS (search_result);
CREATE TABLE search_result_negative
(
CONSTRAINT search_result_negative_polarization_check CHECK (polarization = (-1))
)
INHERITS (search_result);
CREATE TABLE search_result_unpolarized
(
CONSTRAINT search_result_unpolarized_polarization_check CHECK (polarization IS NULL)
)
INHERITS (search_result);
When I execute a query using "WHERE polarization = 1", for example, the query planner will show that it has only checked the "search_result_positive": table, which is the desired behavior.
However, when the query is "WHERE polarization IS NULL", it'll check every single table, taking an immense amount of time. Here's an example for "search_result_positive":
SELECT "search_result".* FROM "search_result" WHERE (polarization = 1) ORDER BY published_on DESC LIMIT 20;
Limit (cost=0.44..17.65 rows=20 width=2027) (actual time=3.638..3.666 rows=20 loops=1)
-> Merge Append (cost=0.44..249453.67 rows=289872 width=2027) (actual time=3.637..3.663 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.004..0.004 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization = 1)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245830.25 rows=289871 width=2027) (actual time=3.633..3.658 rows=20 loops=1)
Filter: (polarization = 1)
Planning time: 2.640 ms
Execution time: 3.762 ms
And now, this is what happens when we query for null:
SELECT "search_result".* FROM "search_result" WHERE (polarization IS NULL) ORDER BY published_on DESC LIMIT 20;
Limit (cost=1.93..143.83 rows=20 width=1758) (actual time=205790.210..206266.419 rows=20 loops=1)
-> Merge Append (cost=1.93..462744.74 rows=65221 width=1758) (actual time=205790.208..206266.403 rows=20 loops=1)
Sort Key: search_result.published_on DESC
-> Sort (cost=0.01..0.02 rows=1 width=2882) (actual time=0.006..0.006 rows=0 loops=1)
Sort Key: search_result.published_on DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on search_result (cost=0.00..0.00 rows=1 width=2882) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan using ix_search_result_hybrid_published_on_desc on search_result_hybrid (cost=0.14..44.44 rows=1 width=2882) (actual time=0.002..0.002 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_negative_published_on_asc on search_result_negative (cost=0.42..126163.49 rows=1 width=2039) (actual time=44646.431..44646.431 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 174428
-> Index Scan Backward using ix_search_result_neutral_published_on_asc on search_result_neutral (cost=0.42..53749.59 rows=1 width=1996) (actual time=29539.393..29539.393 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 115678
-> Index Scan using ix_search_result_no_apply_published_on_desc on search_result_no_apply (cost=0.14..44.44 rows=1 width=2882) (actual time=0.003..0.003 rows=0 loops=1)
Filter: (polarization IS NULL)
-> Index Scan Backward using ix_search_result_positive_published_on_asc on search_result_positive (cost=0.42..245105.57 rows=1 width=2027) (actual time=131590.509..131590.509 rows=0 loops=1)
Filter: (polarization IS NULL)
Rows Removed by Filter: 295475
-> Index Scan using ix_search_result_unpolarized_published_on_desc on search_result_unpolarized (cost=0.29..35643.06 rows=65215 width=1758) (actual time=13.863..490.048 rows=20 loops=1)
Filter: (polarization IS NULL)
Planning time: 1.197 ms
Execution time: 206266.593 ms
This is driving me crazy. I don't understand why every table is being checked instead of only "search_result_unpolarized". This is driving me crazy already. The only other choice I have for this is to rewrite part of our system to query only a specific table instead of letting Postgres decide, which will be a fair amount of work. There must be a better way. Any help or ideas would be greatly appreciated.
We're using Postgres 9.3.19 on Amazon RDS
postgresql optimization execution-plan postgresql-9.3
postgresql optimization execution-plan postgresql-9.3
edited Jul 6 '18 at 5:47
Anthony Genovese
1,7072924
1,7072924
asked Jul 5 '18 at 21:11
MarceloJMarceloJ
312
312
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
2
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
1
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
1
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint thatcheck (polarization is not null)
but first you need to move null values out of child tables.
– Yavuz Selim
Mar 9 at 21:33
add a comment |
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
2
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
1
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
1
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint thatcheck (polarization is not null)
but first you need to move null values out of child tables.
– Yavuz Selim
Mar 9 at 21:33
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
2
2
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
1
1
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
1
1
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint that
check (polarization is not null)
but first you need to move null values out of child tables.– Yavuz Selim
Mar 9 at 21:33
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint that
check (polarization is not null)
but first you need to move null values out of child tables.– Yavuz Selim
Mar 9 at 21:33
add a comment |
1 Answer
1
active
oldest
votes
Constraint exclusion has some caveats. This very case (that non-NULL-ness is not considered, even when the existing check implicates it) is not listed in the documentation, but it's still there in later versions, too. The solution is to add another check that explicitly excludes NULLs:
ALTER TABLE search_result_positive ADD CHECK (polarization IS NOT NULL);
ALTER TABLE search_result_negative ADD CHECK (polarization IS NOT NULL);
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f211477%2fpostgres-query-planner-not-respecting-table-inheritance-constraint-when-queryin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Constraint exclusion has some caveats. This very case (that non-NULL-ness is not considered, even when the existing check implicates it) is not listed in the documentation, but it's still there in later versions, too. The solution is to add another check that explicitly excludes NULLs:
ALTER TABLE search_result_positive ADD CHECK (polarization IS NOT NULL);
ALTER TABLE search_result_negative ADD CHECK (polarization IS NOT NULL);
add a comment |
Constraint exclusion has some caveats. This very case (that non-NULL-ness is not considered, even when the existing check implicates it) is not listed in the documentation, but it's still there in later versions, too. The solution is to add another check that explicitly excludes NULLs:
ALTER TABLE search_result_positive ADD CHECK (polarization IS NOT NULL);
ALTER TABLE search_result_negative ADD CHECK (polarization IS NOT NULL);
add a comment |
Constraint exclusion has some caveats. This very case (that non-NULL-ness is not considered, even when the existing check implicates it) is not listed in the documentation, but it's still there in later versions, too. The solution is to add another check that explicitly excludes NULLs:
ALTER TABLE search_result_positive ADD CHECK (polarization IS NOT NULL);
ALTER TABLE search_result_negative ADD CHECK (polarization IS NOT NULL);
Constraint exclusion has some caveats. This very case (that non-NULL-ness is not considered, even when the existing check implicates it) is not listed in the documentation, but it's still there in later versions, too. The solution is to add another check that explicitly excludes NULLs:
ALTER TABLE search_result_positive ADD CHECK (polarization IS NOT NULL);
ALTER TABLE search_result_negative ADD CHECK (polarization IS NOT NULL);
answered 31 mins ago
dezsodezso
22.6k116097
22.6k116097
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f211477%2fpostgres-query-planner-not-respecting-table-inheritance-constraint-when-queryin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is this supposed to work in PG 9.3?
– Colin 't Hart
Jul 6 '18 at 7:04
2
Also, 9.3 is very old. Strongly recommend upgrading to 10.
– Colin 't Hart
Jul 6 '18 at 10:55
I think that is a limitation of the old inheritance based partitioning.
– a_horse_with_no_name
Jul 6 '18 at 11:35
1
I agree, we need to update. I just checked, we have a different database with the same schema on 9.6, same problem occurs. However, what confuses me is why it works with polarization = 1 but not polarization is null
– MarceloJ
Jul 6 '18 at 13:05
1
I know it is nearly 1 year but PostgreSQL scan all child tables because you have null values on them. You need to add one more constaint that
check (polarization is not null)
but first you need to move null values out of child tables.– Yavuz Selim
Mar 9 at 21:33