systabinfo.ti_serialv
...in 9.30HC5, HP-UX11i Just a little one (as Obnoxio might say) - when I query this column for all ti_partnums of a fragmented table, I get one value for each fragment - one of which has what appears to be the true highest/most recently issued serial value in the table and the others are always set to "1". It seems the fragment partnum returning the real value is the one that is first defined in the schema; is that a fair assessment? Why do the others return "1"? Just interested, is all (yes I know how to use dbinfo and/or sqlca to get the serial value returned by an insert, I'm just looking around proactively in case any of our serials start approaching 2^31). TIA Malc
> From: iiug@perrior.net > Subject: systabinfo.ti_serialv > Date: Thu, 12 Feb 2009 06:54:57 -0800 > To: informix-list@iiug.org > > ...in 9.30HC5, HP-UX11i > > Just a little one (as Obnoxio might say) - when I query this column > for all ti_partnums of a fragmented table, I get one value for each > fragment - one of which has what appears to be the true highest/most > recently issued serial value in the table and the others are always > set to "1". It seems the fragment partnum returning the real value is > the one that is first defined in the schema; is that a fair > assessment? Why do the others return "1"? Just interested, is all (yes > I know how to use dbinfo and/or sqlca to get the serial value returned > by an insert, I'm just looking around proactively in case any of our > serials start approaching 2^31). > > TIA > > Malc There can be only one. ;-) Ok, the point is that for each table, you can only have one SERIAL data type. So it sounds like the last partition touched by an insert contains the correct serial value and the others are set to 1 so that you know which of the values are accurate. You can test this out by creating a partitioned table and insert known values which should hit a known partition. As to the 2^31 -1 limit of SERIAL, why not alter the table and go to SERIAL8. That way when you actually wrap the value, you'll have long since retired. ;-) _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009
Ian Michael Gumby wrote: > > > > From: iiug@perrior.net > > Subject: systabinfo.ti_serialv > > Date: Thu, 12 Feb 2009 06:54:57 -0800 > > To: informix-list@iiug.org > > > > ...in 9.30HC5, HP-UX11i > > > > Just a little one (as Obnoxio might say) - when I query this column > > for all ti_partnums of a fragmented table, I get one value for each > > fragment - one of which has what appears to be the true highest/most > > recently issued serial value in the table and the others are always > > set to "1". It seems the fragment partnum returning the real value is > > the one that is first defined in the schema; is that a fair > > assessment? Why do the others return "1"? Just interested, is all (yes > > I know how to use dbinfo and/or sqlca to get the serial value returned > > by an insert, I'm just looking around proactively in case any of our > > serials start approaching 2^31). > > > > TIA > > > > Malc > > There can be only one. ;-) > > Ok, the point is that for each table, you can only have one SERIAL data > type. > So it sounds like the last partition touched by an insert contains the > correct serial value and the others are set to 1 so that you know which > of the values are accurate. You can test this out by creating a > partitioned table and insert known values which should hit a known > partition. > > As to the 2^31 -1 limit of SERIAL, why not alter the table and go to > SERIAL8. That way when you actually wrap the value, you'll have long > since retired. ;-) > > > ------------------------------------------------------------------------ > Windows Live': Keep your life in sync. See how it works. > <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>; > > That's what serial8 is for > > > > It ranges to 9,223,372,036,854,775,807 which is probably enough for most > > applications > I know. Its a large number. But I'm starting to see some applications > where its possible to surpass that number. > Remember this doesn't mean that the table has to hold that many rows > since they can be purged, but the serial counter will continue to > grow.
I'm sorry, but perhaps I missed something. It looks like you took two of my posts and put them together? I don't want to assume anything, but I think the point you were trying to make was that in one post I was saying that its possible to actually wrap a SERIAL8 and in this thread I said use a SERIAL8 because it will take a while to actually use that many rows? If so, there isn't really any contradiction. The majority of the applications out there won't live long enough to go beyond the SERIAL8 unless some joked decides to enter a row with a value close to the 2^63 -1 limit. A hotel or airline reservation system could be running for years without even coming close. But there are a couple of areas where you can be generating enough data fast enough that you could hit the limit. An example? Suppose you were logging network traffic on an Internet2 link? Theoretical transfer limits are roughly 450GB per min. (100Gbps * 60 / 8) Now I don't think Malcolm works for the NSA so I don't believe he's doing any deep packet sniffing, nor is he working for CERN which will create massive amounts of data when they attempt to create mini black holes and will doom this planet. (If you believe the lawsuit filed in Hi.) Nor does he work for Los Alamos where you have super computers attempting to model nuclear explosions... Does that help clarify the posts? > From: theBP@Usenet-News.Net > Subject: Re: systabinfo.ti_serialv > Date: Thu, 12 Feb 2009 21:37:32 +0000 > To: informix-list@iiug.org > > Ian Michael Gumby wrote: > > > > > > > From: iiug@perrior.net > > > Subject: systabinfo.ti_serialv > > > Date: Thu, 12 Feb 2009 06:54:57 -0800 > > > To: informix-list@iiug.org > > > > > > ...in 9.30HC5, HP-UX11i > > > > > > Just a little one (as Obnoxio might say) - when I query this column > > > for all ti_partnums of a fragmented table, I get one value for each > > > fragment - one of which has what appears to be the true highest/most > > > recently issued serial value in the table and the others are always > > > set to "1". It seems the fragment partnum returning the real value is > > > the one that is first defined in the schema; is that a fair > > > assessment? Why do the others return "1"? Just interested, is all (yes > > > I know how to use dbinfo and/or sqlca to get the serial value returned > > > by an insert, I'm just looking around proactively in case any of our > > > serials start approaching 2^31). > > > > > > TIA > > > > > > Malc > > > > There can be only one. ;-) > > > > Ok, the point is that for each table, you can only have one SERIAL data > > type. > > So it sounds like the last partition touched by an insert contains the > > correct serial value and the others are set to 1 so that you know which > > of the values are accurate. You can test this out by creating a > > partitioned table and insert known values which should hit a known > > partition. > > > > As to the 2^31 -1 limit of SERIAL, why not alter the table and go to > > SERIAL8. That way when you actually wrap the value, you'll have long > > since retired. ;-) > > > > > > ------------------------------------------------------------------------ > > Windows Live™: Keep your life in sync. See how it works. > > <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>; > > > That's what serial8 is for > > > > > > It ranges to 9,223,372,036,854,775,807 which is probably enough for most > > > applications > > > I know. Its a large number. But I'm starting to see some applications > > where its possible to surpass that number. > > Remember this doesn't mean that the table has to hold that many rows > > since they can be purged, but the serial counter will continue to > > grow. > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Faster_022009