On Mar 31, 2017 2:17 PM, "Peter Geoghegan" wrote:
On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> The patch does actually store truncated/key-only tuples in the hi keys /
>> non-leaf-nodes, which don't need the "included" columns.
>
> Hm. Since index tuples lack any means of indicating the
I don't see why you'd necessarily need to know where in the index the tuple
came from under my proposal. Besides, as I already pointed out, we already
hard code minus infinity handling within internal pages during tuple
comparisons.
Anastasia's patch could modify nbtree in exactly the same way as
Peter Geoghegan writes:
> On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
>> ... I also think we're setting up a situation where tools
>> like amcheck and pg_filedump are going to be unable to cope, because
>> figuring out what a particular tuple contains is going to require context
>> they have
On Fri, Mar 31, 2017 at 3:03 PM, Tom Lane wrote:
> The reason it works fine for heap tuples is that heap tuple headers
> explicitly record the number of attributes in the tuple. Index
> tuples don't.
Per my previous mail, I think we can change things so that Index
tuples effectively record that
Robert Haas writes:
> On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
>> It just seems way too dangerous.
> So, we end up with heap tuples with different numbers of attributes
> all the time, whenever you add a column. It works fine - on decoding,
> the additional columns will be treated as nu
I wrote:
> Andres Freund writes:
>> It'd be useful for FieldStore - we'd not have to error out anymore if
>> the number of columns changes (which I previously had "solved" by using
>> MaxHeapAttributeNumber sized values/nulls array).
> Ah, I see. But in that case you're not really truncating the
On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
> I think you are failing to get the point. I am not on about whether
> we need a few bytes more or less, I am on about whether the patch
> even works. As an example, it's quite unclear what the width of
> such an index tuple's nulls bitmap will b
On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>>> Hm. Since index tuples lack any means of indicating the actual number
>>> of columns included (ie there's no equivalent of the natts field that
>>> exists in HeapTu
Peter Geoghegan writes:
> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> Hm. Since index tuples lack any means of indicating the actual number
>> of columns included (ie there's no equivalent of the natts field that
>> exists in HeapTupleHeaders), I think that this is an unreasonably
>> dan
On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> The patch does actually store truncated/key-only tuples in the hi keys /
>> non-leaf-nodes, which don't need the "included" columns.
>
> Hm. Since index tuples lack any means of indicating the actual number
> of columns included (ie there's no e
Robert Haas writes:
> You might want to have a read through that patch. I think your
> opinion would be helpful in determining how close that patch is to
> being ready to commit (same for WARM).
Well, now that we have an extra week, maybe I'll find the time.
regards, tom
Andres Freund writes:
> On 2017-03-31 13:44:52 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> The covering indexes patch [1] really needs a version of
>>> heap_form_tuple/index_form_tuple that allows to specify the number of
>>> columns in the to-be generated tuple.
>> I was thinking about
On 2017-03-31 13:44:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The covering indexes patch [1] really needs a version of
> > heap_form_tuple/index_form_tuple that allows to specify the number of
> > columns in the to-be generated tuple.
>
> I was thinking about that this morning, and wo
On Fri, Mar 31, 2017 at 1:44 PM, Tom Lane wrote:
> Andres Freund writes:
>> The covering indexes patch [1] really needs a version of
>> heap_form_tuple/index_form_tuple that allows to specify the number of
>> columns in the to-be generated tuple.
>
> I was thinking about that this morning, and wo
Andres Freund writes:
> The covering indexes patch [1] really needs a version of
> heap_form_tuple/index_form_tuple that allows to specify the number of
> columns in the to-be generated tuple.
I was thinking about that this morning, and wondering why exactly it
would need such a thing. Certainly
On Fri, Mar 31, 2017 at 1:24 PM, Andres Freund wrote:
> The covering indexes patch [1] really needs a version of
> heap_form_tuple/index_form_tuple that allows to specify the number of
> columns in the to-be generated tuple. Previously the faster expression
> evaluation stuff could also have bene
Hi,
The covering indexes patch [1] really needs a version of
heap_form_tuple/index_form_tuple that allows to specify the number of
columns in the to-be generated tuple. Previously the faster expression
evaluation stuff could also have benefited form the same for both
forming and deforming tuples.
17 matches
Mail list logo
