GH-37538: [Go] Cheaper initial dictionary implementation

[brancz]

Rationale for this change

We've observed that starting with an initial dictionary can be unnecessarily expensive, so we explored ways to achieve the same (or similar) behavior.

What changes are included in this PR?

Prepending dictionaries instead of inserting them into the memotable.

Are these changes tested?

No this is just a sketch for discussion purposes.

Are there any user-facing changes?

n/a for the moment

• Closes: [Go] Allow prepending dictionary arrow-go#47
• GitHub Issue: ARROW-83: [C++] Add basic test infrastructure for DecimalType #47

[brancz]

cc @zeroshade

[brancz]

This doesn't work, it's just a sketch for discussion purposes.

[github-actions]

⚠️ GitHub issue apache/arrow-go#47 has been automatically assigned in GitHub to PR creator.

[zeroshade]

@brancz can you throw together a sketched example as to when/why someone would use this (that could eventually be turned into a unit test)?

[brancz]

@zeroshade added one of my use cases for this. Note that in this simplistic example, I could have also built the indices entirely separately without a dictionary builder and just call new dictionary array with the indices and dictionary, however, when you have deeply nested lists and structs then you don't have this option as you can't control the list and struct offsets, so you rely on the builders that the record builder exposes to you, which in this case is the binary dictionary builder.

[zeroshade]

Thanks @brancz I'll try to take a look at this over the weekend or early next week and see if it makes sense as an approach to pursue

[zeroshade]

@brancz Sorry for the long delay here, but I can see the sense and idea behind your suggestion here. It also doesn't seem like it would be very problematic to allow so I'd be in favor of you fleshing this out to a viable PR that works (as opposed to just a sketch).

[github-actions]

⚠️ GitHub issue #37538 has no components, please add labels for components.