Are you still working on this patch?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Blake,
I've taken the liberty of adding this patch to the current Commitfest.
In future, please continue to send patches both to this thread and to
the commitfest application when you have a message ID for them :)
Cheers,
David.
On Mon, Sep 09, 2013 at 09:55:01AM -0500, Blake Smith wrote:
> Than
Blake,
Teodor will review your patch, but I have one consideration about the patch
in context of future hstore, which supports hierarchical structures. In
that case overhead of composite keys will be enormous and the only way in
this direction is to think about idea suffix array instead of btree t
Thanks for getting back to me about this change Oleg. I took your advice
and reworked the patch by adding a new hstore gin opclass
(gin_hstore_combined_ops) and leaving the functionality of the default
hstore gin opclass the same. This should prevent the on-disk compatibility
issues from the first
On 9/5/13 2:42 PM, Blake Smith wrote:
> Thanks for checking the tests. I wasn't able to duplicate your test
> results. Did you run the hstore regression tests with the revised patch
> I attached in the thread? Attached is the output I got with the latest
> patch applied.
See
http://pgci.eisentrau
Blake,
I think it's better to implement this patch as a separate opclass, so users
will have option to choose indexing.
Oleg
On Tue, Sep 3, 2013 at 6:24 PM, Blake Smith wrote:
> Thanks for the feedback everyone. I've attached the patch that we are now
> running in production to service our hs
Hi Peter,
Thanks for checking the tests. I wasn't able to duplicate your test
results. Did you run the hstore regression tests with the revised patch I
attached in the thread? Attached is the output I got with the latest patch
applied.
Thanks!
Blake
On Tue, Sep 3, 2013 at 8:04 PM, Peter Eise
Thanks for the feedback everyone. I've attached the patch that we are now
running in production to service our hstore include queries. We rebuilt the
index to account for the on-disk incompatibility. I've submitted the patch
to commitfest here:
https://commitfest.postgresql.org/action/patch_view?id
On 2013-08-28 13:31:22 -0400, Bruce Momjian wrote:
> On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> > > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith
> > > wrote:
> > >> The combined entry is used to support "contains (@>)" queries, and the
> > >> key
>
On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote:
> >> The combined entry is used to support "contains (@>)" queries, and the key
> >> only item is used to support "key contains (?)" queries. This change se
Michael, take a look on http://obartunov.livejournal.com/171959.html
As for the indexing stuff we already thought many times about key&value
mixing, but real solution, probably, could come from spgist and gin
combination. I mean, spgist (suffix array) instead of btree for avoiding
key duplication
Michael Paquier writes:
> On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote:
>> The combined entry is used to support "contains (@>)" queries, and the key
>> only item is used to support "key contains (?)" queries. This change seems
>> to help especially with hstore keys that have high cardinal
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote:
> We've been experiencing slow "@>" queries involving an hstore column that's
> covered by a Gin index. At the current postgresql git HEAD, the hstore <->
> gin interface produces the following text items to be indexed:
>
> hstore: "'a'=>'1234',
Hey everyone,
I'm looking for feedback on a contrib/hstore patch.
We've been experiencing slow "@>" queries involving an hstore column that's
covered by a Gin index. At the current postgresql git HEAD, the hstore <->
gin interface produces the following text items to be indexed:
hstore: "'a'=>'1
14 matches
Mail list logo
