Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Mon, Jul 4, 2016 at 2:30 AM, Heikki Linnakangas wrote: > I think we should pack the TIDs more tightly, like GIN does with the varbyte > encoding. It's tempting to commit this without it for now, and add the > compression later, but I'd like to avoid having to deal with

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 18/03/16 19:19, Anastasia Lubennikova wrote: Please, find the new version of the patch attached. Now it has WAL functionality. Detailed description of the feature you can find in README draft https://goo.gl/50O8Q0 This patch is pretty complicated, so I ask everyone, who interested in this

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Mar 24, 2016 at 7:12 PM, Peter Geoghegan wrote: > On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: >> I really like this idea, and the performance results seem impressive, >> but I think we should push this out to 9.7. A btree patch that didn't

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

25.03.2016 01:12, Peter Geoghegan: On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: I really like this idea, and the performance results seem impressive, but I think we should push this out to 9.7. A btree patch that didn't have WAL support until two and a half weeks

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 3/24/16 10:21 AM, Alexander Korotkov wrote: 1) It's a great feature many users dream about. Doesn't matter if it starts eating their data... 2) Patch is not very big. 3) Patch doesn't introduce significant infrastructural changes. It just change some well-isolated placed. It doesn't

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: > I really like this idea, and the performance results seem impressive, > but I think we should push this out to 9.7. A btree patch that didn't > have WAL support until two and a half weeks into the final CommitFest >

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Mar 24, 2016 at 5:17 PM, Robert Haas wrote: > On Fri, Mar 18, 2016 at 1:19 PM, Anastasia Lubennikova > wrote: > > Please, find the new version of the patch attached. Now it has WAL > > functionality. > > > > Detailed description of

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Fri, Mar 18, 2016 at 1:19 PM, Anastasia Lubennikova wrote: > Please, find the new version of the patch attached. Now it has WAL > functionality. > > Detailed description of the feature you can find in README draft > https://goo.gl/50O8Q0 > > This patch is pretty

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 18.03.2016 20:19, Anastasia Lubennikova wrote: Please, find the new version of the patch attached. Now it has WAL functionality. Detailed description of the feature you can find in README draft https://goo.gl/50O8Q0 This patch is pretty complicated, so I ask everyone, who interested in

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

Please, find the new version of the patch attached. Now it has WAL functionality. Detailed description of the feature you can find in README draft https://goo.gl/50O8Q0 This patch is pretty complicated, so I ask everyone, who interested in this feature, to help with reviewing and testing

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

14.03.2016 16:02, David Steele: Hi Anastasia, On 2/18/16 12:29 PM, Anastasia Lubennikova wrote: 18.02.2016 20:18, Anastasia Lubennikova: 04.02.2016 20:16, Peter Geoghegan: On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: I fixed it in the new

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

Hi Anastasia, On 2/18/16 12:29 PM, Anastasia Lubennikova wrote: 18.02.2016 20:18, Anastasia Lubennikova: 04.02.2016 20:16, Peter Geoghegan: On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: I fixed it in the new version (attached). Thank you for

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

18.02.2016 20:18, Anastasia Lubennikova: 04.02.2016 20:16, Peter Geoghegan: On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: I fixed it in the new version (attached). Thank you for the review. At last, there is a new patch version 3.0. After some

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Tue, Feb 2, 2016 at 3:59 AM, Thom Brown wrote: > public | pgbench_accounts_pkey | index | thom | pgbench_accounts | 214 MB | > public | pgbench_branches_pkey | index | thom | pgbench_branches | 24 kB | > public | pgbench_tellers_pkey | index | thom | pgbench_tellers |

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Feb 4, 2016 at 8:25 AM, Thom Brown wrote: > > No, I'm not. I've just realised that all I've been checking is the > primary key expecting it to change in size, which is, of course, > nonsense. I should have been creating an index on the bid field of > pgbench_accounts and

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 4 February 2016 at 15:07, Peter Geoghegan wrote: > On Tue, Feb 2, 2016 at 3:59 AM, Thom Brown wrote: >> public | pgbench_accounts_pkey | index | thom | pgbench_accounts | 214 MB | >> public | pgbench_branches_pkey | index | thom | pgbench_branches | 24 kB

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: > I fixed it in the new version (attached). Some quick remarks on your V2.0: * Seems unnecessary that _bt_binsrch() is passed a real pointer by all callers. Maybe the one current posting list caller

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

29.01.2016 20:43, Thom Brown: On 29 January 2016 at 16:50, Anastasia Lubennikova wrote: 29.01.2016 19:01, Thom Brown: On 29 January 2016 at 15:47, Aleksander Alekseev wrote: I tested this patch on x64 and ARM servers for a few

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 2 February 2016 at 11:47, Anastasia Lubennikova wrote: > > > 29.01.2016 20:43, Thom Brown: > >> On 29 January 2016 at 16:50, Anastasia Lubennikova >> wrote: >>> >>> 29.01.2016 19:01, Thom Brown: On 29 January 2016 at

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

28.01.2016 20:03, Thom Brown: On 28 January 2016 at 16:12, Anastasia Lubennikova > wrote: 28.01.2016 18:12, Thom Brown: On 28 January 2016 at 14:06, Anastasia Lubennikova

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

29.01.2016 19:01, Thom Brown: On 29 January 2016 at 15:47, Aleksander Alekseev wrote: I tested this patch on x64 and ARM servers for a few hours today. The only problem I could find is that INSERT works considerably slower after applying a patch. Beside that

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 29 January 2016 at 15:47, Aleksander Alekseev wrote: > I tested this patch on x64 and ARM servers for a few hours today. The > only problem I could find is that INSERT works considerably slower after > applying a patch. Beside that everything looks fine - no crashes,

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

I tested this patch on x64 and ARM servers for a few hours today. The only problem I could find is that INSERT works considerably slower after applying a patch. Beside that everything looks fine - no crashes, tests pass, memory doesn't seem to leak, etc. > Okay, now for some badness. I've

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 29 January 2016 at 16:50, Anastasia Lubennikova wrote: > 29.01.2016 19:01, Thom Brown: >> >> On 29 January 2016 at 15:47, Aleksander Alekseev >> wrote: >>> >>> I tested this patch on x64 and ARM servers for a few hours today. The >>>

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Jan 28, 2016 at 9:03 AM, Thom Brown wrote: > I'm surprised that efficiencies can't be realised beyond this point. Your > results show a sweet spot at around 1000 / 1000, with it getting slightly > worse beyond that. I kind of expected a lot of efficiency where all

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

28.01.2016 18:12, Thom Brown: On 28 January 2016 at 14:06, Anastasia Lubennikova > wrote: 31.08.2015 10:41, Anastasia Lubennikova: Hi, hackers! I'm going to begin work on effective storage of duplicate keys in

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 28 January 2016 at 17:09, Peter Geoghegan wrote: > On Thu, Jan 28, 2016 at 9:03 AM, Thom Brown wrote: >> I'm surprised that efficiencies can't be realised beyond this point. Your >> results show a sweet spot at around 1000 / 1000, with it getting >>

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 28 January 2016 at 17:03, Thom Brown wrote: > > On 28 January 2016 at 16:12, Anastasia Lubennikova < > a.lubennik...@postgrespro.ru> wrote: > >> >> 28.01.2016 18:12, Thom Brown: >> >> On 28 January 2016 at 14:06, Anastasia Lubennikova < >> a.lubennik...@postgrespro.ru> wrote:

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

31.08.2015 10:41, Anastasia Lubennikova: Hi, hackers! I'm going to begin work on effective storage of duplicate keys in B-tree index. The main idea is to implement posting lists and posting trees for B-tree index pages as it's already done for GIN. In a nutshell, effective storing of

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 28 January 2016 at 16:12, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > 28.01.2016 18:12, Thom Brown: > > On 28 January 2016 at 14:06, Anastasia Lubennikova < > a.lubennik...@postgrespro.ru> wrote: > >> >> 31.08.2015 10:41, Anastasia Lubennikova: >> >> Hi, hackers! >> I'm

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 28 January 2016 at 14:06, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > 31.08.2015 10:41, Anastasia Lubennikova: > > Hi, hackers! > I'm going to begin work on effective storage of duplicate keys in B-tree > index. > The main idea is to implement posting lists and posting