Re: Table with ~255+ columns

The answer to that question may be dependent on the version of Oracle and on how the row got to the state it was in before the update to null of the 276th column.

The first point to consider, though, is that the row HAS to be in at least two pieces if *any *column after the 255th is non-null, so updating just the 276th isn't likely to have any significant effect. Given that you're on 11.2.0.4 I doubt if Oracle will do anything nice all you do is set that column to null - in fact it may simply find another way of doing something nasty, but you'd have to do some experiments to find out what that could be.

Regards
Jonathan Lewis

On Sun, 29 Nov 2020 at 19:55, Lok P <loknath.73_at_gmail.com> wrote:

> One thing i saw, few of the stats gather statements on this table are
> logging heavy statistics "table fetch continued row" on this table, And
> another thing i notice, as per the NULL/NOT NULL data pattern i published
> from one of the sample partition, it shows out of total 277 columns , we
> have 276th position column populated with NOT NULL value for almost all the
> rows, so its confirm that we must be having the rows split into two parts
> as we have 276th column inserted as NOT NULL. And , as we have the row size
> restricted to ~avg ~277bytes, so my thought was , at max it will intra row
> chaining considering we are not updating the columns in this table. But
> then I observed in old partitions that the 276th position column is UPDATED
> to NULL value for all of those rows, so in that case will Oracle try to
> readjust them into a single piece again, or it will be in the same two
> rowpiece only?
>
>

--
http://www.freelists.org/webpage/oracle-l