I wrote:
> Alvaro Herrera writes:
>> Would it make sense to remove the only the few oldest entries, instead
>> of all of them? As is, I think this causes a storm of reloads every
>> once in a while, if the number of FKs in the system is large enough.
>> Maybe on a cache hit we could push the entr
Alvaro Herrera writes:
> Would it make sense to remove the only the few oldest entries, instead
> of all of them? As is, I think this causes a storm of reloads every
> once in a while, if the number of FKs in the system is large enough.
> Maybe on a cache hit we could push the entry to the head o
Tom Lane wrote:
> Jan Wieck writes:
> > Attached is a complete rework of the fix from scratch, based on Tom's
> > suggestion.
>
> > The code now maintains a double linked list as suggested, but only uses
> > it to mark all currently valid entries as invalid when hashvalue == 0.
> > If a specif
Jan Wieck writes:
> On 09/18/2015 10:47 AM, Tom Lane wrote:
>> Attached is something closer to what I was envisioning; can you do
>> performance testing on it?
> Yes, that patch also has the desired performance for restoring a schema
> with hundreds of thousands of foreign key constraints.
Grea
On 09/18/2015 10:47 AM, Tom Lane wrote:
Jan Wieck writes:
Attached is a complete rework of the fix from scratch, based on Tom's
suggestion.
The code now maintains a double linked list as suggested, but only uses
it to mark all currently valid entries as invalid when hashvalue == 0.
If a spec
Jan Wieck writes:
> Attached is a complete rework of the fix from scratch, based on Tom's
> suggestion.
> The code now maintains a double linked list as suggested, but only uses
> it to mark all currently valid entries as invalid when hashvalue == 0.
> If a specific entry is invalidated it per
On 09/15/2015 12:02 PM, Jan Wieck wrote:
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is that it's not the size of the cache that's
Jan Wieck writes:
> Would it be appropriate to use (Un)RegisterXactCallback() in case of
> detecting excessive sequential scanning of that cache and remove all
> invalid entries from it at that time?
Don't see how unregistering the callback would help?
In any case, I'm -1 on this entire concep
On 09/15/2015 10:58 AM, Tom Lane wrote:
I wrote:
Jan Wieck writes:
I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
definitely is caused by this commit. Do you want to back it out for the
time being? Kevin is on vacation right now.
I'll take a look today, and either fix i
I wrote:
> Jan Wieck writes:
>> I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
>> definitely is caused by this commit. Do you want to back it out for the
>> time being? Kevin is on vacation right now.
> I'll take a look today, and either fix it if I can find the problem
> q
On 09/15/2015 09:51 AM, Tom Lane wrote:
Jan Wieck writes:
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I
Jan Wieck writes:
> On 09/14/2015 09:56 AM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> Fix an O(N^2) problem in foreign key references.
>> Judging from the buildfarm, this patch is broken under
>> CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
>> I might be too quick to finger
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I might be too quick to finger this patch, but nothing else
late
Kevin Grittner writes:
> Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I might be too quick to finger this patch, but nothing else
lately has touched foreign-key behavior, and t
15 matches
Mail list logo