| 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: | Whole Thread | Raw Message | 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 |