Re: [HACKERS] Refactoring of heapam code.

2016-09-26 Thread Pavan Deolasee
On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.09.2016 07:44, Pavan Deolasee: > > > I don't know what to do with the CF entry itself. I could change the > status to "waiting on author" but then the design draft may not get enough > attention. So

Re: [HACKERS] Refactoring of heapam code.

2016-09-13 Thread Michael Paquier
On Mon, Sep 12, 2016 at 7:12 PM, Pavan Deolasee wrote: > I was thinking about locking, bulk reading (like page-mode API) etc. While > you've added an API for vacuuming, we would probably also need an API to > collect dead tuples, pruning etc (not sure if that can be

Re: [HACKERS] Refactoring of heapam code.

2016-09-12 Thread Pavan Deolasee
On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.09.2016 07:44, Pavan Deolasee: > > 2. I don't understand the difference between PageGetItemHeapHeaderOnly() > and PageGetItemHeap(). They seem to do exactly the same thing and can be > used

Re: [HACKERS] Refactoring of heapam code.

2016-09-06 Thread Anastasia Lubennikova
06.09.2016 07:44, Pavan Deolasee: On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova > wrote: Thank you for the review, I'll fix these problems in final version. Posting the first message I intended to raise

Re: [HACKERS] Refactoring of heapam code.

2016-09-05 Thread Pavan Deolasee
On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > >> > Thank you for the review, I'll fix these problems in final version. > > Posting the first message I intended to raise the discussion. Patches > were attached mainly to illustrate the problem and to

Re: [HACKERS] Refactoring of heapam code.

2016-08-15 Thread Anastasia Lubennikova
08.08.2016 12:43, Anastasia Lubennikova: 08.08.2016 03:51, Michael Paquier: On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: Anastasia Lubennikova wrote: So there is a couple of patches. They do not cover all mentioned problems, but I'd like to get a feedback

Re: [HACKERS] Refactoring of heapam code.

2016-08-08 Thread Alvaro Herrera
Anastasia Lubennikova wrote: > By the way, I thought about looking at the mentioned patch and > probably reviewing it, but didn't find any of your patches on the > current commitfest. Could you point out the thread? Sorry, I haven't posted anything yet. > >Agreed. But changing its name while

Re: [HACKERS] Refactoring of heapam code.

2016-08-08 Thread Anastasia Lubennikova
08.08.2016 03:51, Michael Paquier: On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: Anastasia Lubennikova wrote: So there is a couple of patches. They do not cover all mentioned problems, but I'd like to get a feedback before continuing. I agree that we could

Re: [HACKERS] Refactoring of heapam code.

2016-08-08 Thread Anastasia Lubennikova
05.08.2016 20:56, Alvaro Herrera: Anastasia Lubennikova wrote: Working on page compression and some other issues related to access methods, I found out that the code related to heap looks too complicated. Much more complicated, than it should be. Since I anyway got into this area, I want to

Re: [HACKERS] Refactoring of heapam code.

2016-08-07 Thread Michael Paquier
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: > Anastasia Lubennikova wrote: >> So there is a couple of patches. They do not cover all mentioned problems, >> but I'd like to get a feedback before continuing. > > I agree that we could improve things in this

Re: [HACKERS] Refactoring of heapam code.

2016-08-05 Thread Alvaro Herrera
Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got into this area, I want to suggest a set of improvements.

Re: [HACKERS] Refactoring of heapam code.

2016-08-05 Thread Anastasia Lubennikova
05.08.2016 16:30, Kevin Grittner: On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: They can be logically separated into three categories: "primary storage" - r, S, t, v. They store data and visibility information. The only implementation is heapam.c

Re: [HACKERS] Refactoring of heapam code.

2016-08-05 Thread Kevin Grittner
On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: > They can be logically separated into three categories: > "primary storage" - r, S, t, v. They store data and visibility information. > The only implementation is heapam.c > "secondary index" - i. They

Re: [HACKERS] Refactoring of heapam code.

2016-08-05 Thread Thom Brown
On 5 August 2016 at 08:54, Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got

[HACKERS] Refactoring of heapam code.

2016-08-05 Thread Anastasia Lubennikova
Working on page compression and some other issues related to access methods, I found out that the code related to heap looks too complicated. Much more complicated, than it should be. Since I anyway got into this area, I want to suggest a set of improvements. There is a number of problems I see