| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: HEAD seems to generate larger WAL regarding GIN index |
| Date: | 2014-03-17 14:33:17 |
| Message-ID: | 7544.1395066797@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> 2. Instead of storing the new compressed posting list in the WAL record,
> store only the new item pointers added to the page. WAL replay would
> then have to duplicate the work done in the main insertion code path:
> find the right posting lists to insert to, decode them, add the new
> items, and re-encode.
That sounds fairly dangerous ... is any user-defined code involved in
those decisions?
> This record format would be higher-level, in the sense that we would not
> store the physical copy of the compressed posting list as it was formed
> originally. The same work would be done at WAL replay. As the code
> stands, it will produce exactly the same result, but that's not
> guaranteed if we make bugfixes to the code later, and a master and
> standby are running different minor version. There's not necessarily
> anything wrong with that, but it's something to keep in mind.
Version skew would be a hazard too, all right. I think it's important
that WAL replay be a pretty mechanical, predictable process.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-03-17 14:52:59 | Re: on_exit_reset fails to clear DSM-related exit actions |
| Previous Message | Robert Haas | 2014-03-17 14:29:11 | Re: gaussian distribution pgbench |