From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: speedup tidbitmap patch: cache page |
Date: | 2014-12-23 11:24:43 |
Message-ID: | 549950FB.2050004@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Oh, that makes sense. Though I wonder if you need to clear the caches at all
> when calling tbm_lossify(). Surely it never becomes un-lossified and plus, at
> least for lossy_page it would never be set to the current page anyway, it's
> either going to be set to InvalidBlockNumber, or some other previous page that
agree, fixed
> was lossy. I also can't quite see the need to set page to NULL. Surely doing
> this would just mean we'd have to lookup the page again once tbm_lossify() is
> called if the next loop happened to be the same page? I think this would only be
> needed if the hash lookup was going to return a new instance of the page after
> we've lossified it, which from what I can tell won't happen.
Page could become an invalid pointer, because during tbm_mark_page_lossy()
called from tbm_lossify() it could be freed.
> I've also attached some benchmark results using your original table from
> up-thread. It seems that the caching if the page was seen as lossy is not much
> of a help in this test case. Did you find another one where you saw some better
> gains?
All what I found is about 0.5%... v3 contains your comments but it doesn't use
lossy_page cache.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
Attachment | Content-Type | Size |
---|---|---|
tbm_cachepage-2.3.patch.gz | application/x-gzip | 892 bytes |
tbm_cachepage-3.patch.gz | application/x-gzip | 751 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-12-23 12:11:32 | Re: Missing updates at few places for row level security |
Previous Message | Arne Scheffer | 2014-12-23 11:11:47 | Re: [PATCH] explain sortorder |