| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: BRIN and PageIndexDeleteNoCompact |
| Date: | 2014-11-18 19:46:21 |
| Message-ID: | 20141118194621.GE1948@alvin.alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> BRIN added a new function, PageIndexDeleteNoCompact(), which is like
> PageIndexMultiDelete but does not remove unused line pointers. However, all
> the callers pass it just a single offset. So the callers would really be
> more interested in efficiently squeezing out a single tuple from a page,
> like PageIndexTupleDelete() does, than a bulk operation.
Yeah, I noticed this and yes I agree there's no harm in changing it to a
single-tuple mode rather than bulk operation.
> How about replacing PageIndexDeleteNoCompact() with something more like
> PageIndexTupleDelete()? It ought to be both faster and simpler.
No objection. Are you working on this, or do you intend me to?
How relevant is this given your current PageRepairFragmentation work?
I think it will cause hard merge conflicts if done right away; should it
be attempted prior to the PRF patches, or after it's done? I assume
that if you do it, you can do both things simultaneously ...
> PS. The comment above PageIndexDeleteNoCompact says that unused items at the
> end of the array are removed. But looking at the code, I don't see it doing
> that.
Hmm, it probably lost the capability during the development :-(
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2014-11-18 19:53:17 | Re: proposal: plpgsql - Assert statement |
| Previous Message | Josh Berkus | 2014-11-18 18:50:29 | Re: pg_locks doesn't check for interrupts? |