Re: [HACKERS] Refactoring of heapam code.

2016-09-25 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 I

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 combined with > vacuum). Of cou

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 interchang

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 mailto: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

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 before continuing. I agree

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 ke

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 improve things in this gener

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 sugg

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 general area, but I do not > endo

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. H

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 "secondary index" - i. They stor

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 store some data and pointers to p

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 into this area, I want to sugge

[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 i