From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Virender Singla <virender(dot)cse(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TOAST - why separate visibility map |
Date: | 2021-11-19 20:31:00 |
Message-ID: | 3098396.1637353860@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Virender Singla <virender(dot)cse(at)gmail(dot)com> writes:
> Why do Toast tables have it's own visibility map and xmin, xmax columns etc?
> Isn't it increasing row size in a toast table and adding more complexity?
There are advantages to having the same low-level format for toast tables
as regular tables --- for example, that you can look into a toast table
for debugging purposes with normal SQL queries. Even if we weren't tied
to that format for disk-storage-compatibility reasons, I'd be disinclined
to change it.
It might be feasible to drop the visibility map for toast tables, though.
I agree that's not buying much, since ordinary queries don't consult it.
Not sure if there'd be a win proportional to the added code complexity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-11-19 20:34:51 | Re: [PATCH] Make ENOSPC not fatal in semaphore creation |
Previous Message | Thomas Munro | 2021-11-19 20:18:37 | Re: [PATCH] Make ENOSPC not fatal in semaphore creation |