| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: page macros cleanup (ver 04) |
| Date: | 2008-07-04 12:11:59 |
| Message-ID: | 486E138F.4060900@sun.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Pavan Deolasee napsal(a):
> On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas
> <heikki(at)enterprisedb(dot)com> wrote:
>>
>> No, there's a itemsz = MAXALIGN(itemsz) call before the check against
>> HashMaxItemSize.
>>
>
> Ah, right. Still should we just not MAXALIGN_DOWN the Max size to
> reflect the practical limit on the itemsz ? It's more academical
> though, so not a big deal.
Finally I use following formula:
#define HashMaxItemSize(page) \
MAXALIGN_DOWN(PageGetPageSize(page) - \
( SizeOfPageHeaderData + sizeof(ItemIdData) ) - \
MAXALIGN(sizeof(HashPageOpaqueData)) )
I did not replace PageGetPageSize(page), because other *MaxItemSize has same
interface.
Revised patch is attached.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
| Attachment | Content-Type | Size |
|---|---|---|
| page_04.patch | text/x-patch | 33.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-07-04 12:20:45 | Re: Relation forks & FSM rewrite patches |
| Previous Message | Zdenek Kotala | 2008-07-04 11:47:00 | Re: page macros cleanup |