From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Selectivity estimation for intarray |
Date: | 2015-04-29 16:05:26 |
Message-ID: | 35337.1430323526@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> For the specific cases you mention, perhaps it would be all right if we
>> taught plancache.c to blow away *all* cached plans upon seeing any change
>> in pg_operator; but that seems like a brute-force solution.
> Agreed that it is- but is that really a problem...?
Perhaps it isn't; we certainly have assumptions that pg_amop, for
instance, changes seldom enough that it's not worth tracking individual
changes. The same might be true of pg_operator. I'm not sure though.
The core point I'm trying to make is that making pg_operator entries
mutable is something that's going to require very careful review.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2015-04-29 16:05:44 | Re: FIX : teach expression walker about RestrictInfo |
Previous Message | Stephen Frost | 2015-04-29 15:37:18 | Re: Selectivity estimation for intarray |