Thread: remove useless ccache searching
This patch: https://commitfest.postgresql.org/action/patch_view?id=597 caches the cache because, I guess, the cache is slow. Simon asked, "What is making the first cache so slow?". Pavel does not know, nor how to fix it, and nobody else responded. So my question is: is someone going to take a look at the cache? Should this be accepted as a short term fix (cuz someonewill fix the cache later), long term fix (cuz the cache needs to say as-is), or not at all (because someone will fixcache right now now)? -Andy
Pavel, I have not taken on your patch for review, but I was reading the history of it, and one question popped up: If you are allocating a new cache, what if the array is really big, will 1st cache + your cache get bigger than work_mem? (or are array op's not constrained by work_mem? Sorry, I have not used array's so not sure if there are memorylimits on them) -Andy
Hello 2011/9/5 Andy Colson <andy@squeakycode.net>: > This patch: > > https://commitfest.postgresql.org/action/patch_view?id=597 > > caches the cache because, I guess, the cache is slow. > > Simon asked, "What is making the first cache so slow?". Pavel does not > know, nor how to fix it, and nobody else responded. > > So my question is: is someone going to take a look at the cache? Should > this be accepted as a short term fix (cuz someone will fix the cache later), > long term fix (cuz the cache needs to say as-is), or not at all (because > someone will fix cache right now now)? A idea so this patch is cache of cache is not exact Access to array needs lot of metadata related to element type. These metadata are statics. I can store these data when we first access a variable with data. ccache is relative fast - hash search, but should not be faster than just direct access to structure. This technique is used more time in PL/pgSQL. Regards Pavel > > -Andy > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Hello 2011/9/5 Andy Colson <andy@squeakycode.net>: > Pavel, I have not taken on your patch for review, but I was reading the > history of it, and one question popped up: > > If you are allocating a new cache, what if the array is really big, will 1st > cache + your cache get bigger than work_mem? (or are array op's not > constrained by work_mem? Sorry, I have not used array's so not sure if > there are memory limits on them) this patch doesn't cache a array - it store only a 18 bytes more per array variable - it doesn't depend on array size. but generally, arrays are not limited by work_mem - so if you work with large arrays - you can go out of memory. Regards Pavel > > -Andy >
Andy Colson <andy@squeakycode.net> writes: > This patch: > https://commitfest.postgresql.org/action/patch_view?id=597 > caches the cache because, I guess, the cache is slow. > Simon asked, "What is making the first cache so slow?". Pavel does not know, nor how to fix it, and nobody else responded. Well, the cache doesn't need to be "slow" to make it worthwhile to eliminate repeated cache lookups altogether. We do that in many places. The questions that need to be asked here are whether the speed gain is worthwhile, whether there is any possibility of the locally cached information becoming obsolete, whether it's done in a clean fashion, whether it should be done somewhere else instead of right here. regards, tom lane