From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OOM in spgist insert |
Date: | 2021-05-14 08:27:14 |
Message-ID: | CALT9ZEHLM8+4hPinp=eKF0nJu+Tu8Dwc0koc--T9z-6RW4t6bQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> Now when checking for shortening of leaf tuple is added LongValuesOK
> become slightly redundant. I'd propose to replace it with more legible name
> as LongValuesOK doesn't mean they are warranted to be ok just that we can
> try to shorten them? What about tryShortening, trySuffixing or
> can(Try)ShortenTuple?
>
Or maybe it's even more logical now to invert it and make
dontTrySuffixing for use in the opclasses for kd-tree, quadtree etc which
are warranted to have the same key data length at any tree level ?
--
Best regards,
Pavel Borisov
Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-05-14 08:47:26 | Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |
Previous Message | houzj.fnst@fujitsu.com | 2021-05-14 08:24:43 | RE: Parallel INSERT SELECT take 2 |