Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] [PATCH] pageinspect function to decode infomasks |
Дата | |
Msg-id | CAA4eK1+AE+Pemvpf9yaLfP+s2cU5fENd72BNr8kHBijVyNQHLg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] pageinspect function to decode infomasks (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
|
Список | pgsql-hackers |
On Sat, Sep 14, 2019 at 10:10 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote: > > On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > >> A thought I had as I fell asleep last night is to include the derivate > >> flags in a separate output column altogether. So > >> heap_tuple_infomask_flags() could be made to return two columns, one > >> with the straight one-flag-per-bit, and another one with the compound > >> flags. > > > > So, in most cases, the compound column will be empty, but in some > > cases like HEAP_XMIN_FROZEN, HEAP_XMAX_SHR_LOCK, etc. the flag will be > > displayed. I like this idea though it will be a bit of noise in some > > cases but it is neat. Another benefit is that one doesn't need to > > invoke this function twice to see the compound flags. > > Hmmm. Doesn't it become less user-friendly to invoke the function > then? You would need to pass it down to the FROM clause after > fetching the raw page and then parsing its tuple items to have > t_infomask and t_infomask2 passed down as arguments to the new > function. The one-column version has the advantage to be more > consistent with tuple_data_split() after getting all the values parsed > by heap_page_items(). > Won't 'Lateral' clause be helpful here as the patch contains it in one of its tests? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: