[Info-ingres] When is a table just to damn big?

[Karl and Betty Schendel]

> On Nov 5, 2018, at 5:37 AM, Martin Bowes <martin.bowes at ndph.ox.ac.uk> wrote:
> 
> Hi All,
>  
> On II 10.2.0 (a64.lnx/100) + p15162.
>  
> I have a table which is a tad on the chunky side. And so we have partitioned it 32 ways…
>  
> Name:                 pidrun
> Type:                 user table (partitioned)
> Version:              II10.0
> Number of rows:       2161795407
> Storage structure:    btree with unique keys
> Column Information:
>                                                                           Key
> Column Name                      Type               Length Nulls Defaults Seq
> run_id                           integer                 4   no      no     1
> encoded_id                       integer                 4   no      no     2
> group_id                         integer                 2   no   value      
> status                           integer                 1   no      no     
>  
> partition = (HASH on run_id
>           32 partitions
>         )
>  
> Last week it had  2145691720 rows and we were able to modify it.
>  
> This week the number of rows exceeds an int4 item.
>  
> An attempt to modify the table fails with…
> E_QE0083 Error modifying a table. 
>  
>  
> And in the errlog we see:
> BBA_CTSU_OX_AC_UK ::[40644             , 5706      ,  00007f48abe188c0, sc0m.c:1642           ]: Mon Nov  5 10:26:34 2018 E_SC0107_BAD_SIZE_EXPAND  Error expanding virtual size of server.

That's a weird message.  Do you need the table key to be btree?  Can it be hash?
Hash partitioning doesn't necessarily play well with a btree index.  My other thought
would be to make the partitioning be range partitioning.  I don't know if either will help.
Is the DBMS log enabled and is there anything interesting in there?

Karl