Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
cce442da
Commit
cce442da
authored
Jan 05, 2004
by
Tom Lane
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Dept. of second thoughts: clause_selectivity shouldn't try to cache its
result for jointypes associated with IN processing.
parent
9091e8d1
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
29 additions
and
8 deletions
+29
-8
src/backend/optimizer/path/clausesel.c
src/backend/optimizer/path/clausesel.c
+29
-8
No files found.
src/backend/optimizer/path/clausesel.c
View file @
cce442da
...
...
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.6
3 2004/01/04 03:51:52
tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.6
4 2004/01/05 16:44:40
tgl Exp $
*
*-------------------------------------------------------------------------
*/
...
...
@@ -417,17 +417,38 @@ clause_selectivity(Query *root,
* If possible, cache the result of the selectivity calculation for
* the clause. We can cache if varRelid is zero or the clause
* contains only vars of that relid --- otherwise varRelid will affect
* the result, so mustn't cache. We ignore the possibility that
* jointype will affect the result, which should be okay because outer
* join clauses will always be examined with the same jointype value.
* the result, so mustn't cache. We also have to be careful about
* the jointype. It's OK to cache when jointype is JOIN_INNER or
* one of the outer join types (any given outer-join clause should
* always be examined with the same jointype, so result won't change).
* It's not OK to cache when jointype is one of the special types
* associated with IN processing, because the same clause may be
* examined with different jointypes and the result should vary.
*/
if
(
varRelid
==
0
||
bms_is_subset_singleton
(
rinfo
->
clause_relids
,
varRelid
))
{
/* Cacheable --- do we already have the result? */
if
(
rinfo
->
this_selec
>=
0
)
return
rinfo
->
this_selec
;
cacheable
=
true
;
switch
(
jointype
)
{
case
JOIN_INNER
:
case
JOIN_LEFT
:
case
JOIN_FULL
:
case
JOIN_RIGHT
:
/* Cacheable --- do we already have the result? */
if
(
rinfo
->
this_selec
>=
0
)
return
rinfo
->
this_selec
;
cacheable
=
true
;
break
;
case
JOIN_UNION
:
/* unimplemented anyway... */
case
JOIN_IN
:
case
JOIN_REVERSE_IN
:
case
JOIN_UNIQUE_OUTER
:
case
JOIN_UNIQUE_INNER
:
/* unsafe to cache */
break
;
}
}
/* Proceed with examination of contained clause */
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment