 | |
Re: [Info-Ingres] hash partiton,seconday indicies and SIGSEGV...Urgent!
comp.databases.ingres comp.databases.ingres
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Re: [Info-Ingres] hash partiton,seconday indicies and SIGSEGV...Urgent! -
06-29-2009
, 05:04 AM
|
II 9.0.4 (a64.lnx/105)NPTL + p12707 Over the weekend I altered a table which has several long varchar columns to be hash partitioned 10 ways. The hash key was the same as the btree unique key of the table. [snip] The table has two persistent indexes named gobz_gtyp_status, gobz_pid_gtyp. Since the modify, any attempt to insert into the table will crash the server with a SIGSEGV. |
DBMS servers?
I can't stay that I recall a segv bug quite like this one.
It is a bit odd to be using hash partition with a btree primary key
structure.
That implies that any sort of range scan will have to probe each
partition,
and I'm pretty sure that OPF will end up degenerating anything other
than
equality lookups into table scans. (It might compile a range scan
for each
partition, but you wouldn't be getting rows out in order.) Typically
you'd use range partitioning with btree, or hash partitioning with
hash table structures. I don't see how any of this would cause a
segv upon insert, though.
Karl
#2
| |||
| |||
|
|
II 9.0.4 (a64.lnx/105)NPTL + p12707 Over the weekend I altered a table which has several long varchar columns to be hash partitioned 10 ways. The hash key was the same as the btree unique key of the table. [snip] The table has two persistent indexes named gobz_gtyp_status, gobz_pid_gtyp. Since the modify, any attempt to insert into the table will crash the server with a SIGSEGV. |
DBMS servers?
I can't stay that I recall a segv bug quite like this one.
It is a bit odd to be using hash partition with a btree primary key
structure.
That implies that any sort of range scan will have to probe each
partition,
and I'm pretty sure that OPF will end up degenerating anything other
than
equality lookups into table scans. (It might compile a range scan
for each
partition, but you wouldn't be getting rows out in order.) Typically
you'd use range partitioning with btree, or hash partitioning with
hash table structures. I don't see how any of this would cause a
segv upon insert, though.
Karl
_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://www.kettleriverconsulting.com...fo/info-ingres
#3
| |||
| |||
|
|
And the only reason I'm partitioning this table is to get a lot more blob support tables created. This works around the current bug of the bloody thing stopping when the initial iietab fills up. Which it may not, unless someone has fixed it. When I hooked up partitioning to blobs, my intent was to put each partition's blob segments in separate etabs. And yes, it does create an etab for each partition ... and then proceeds to put all the blob data into etab zero! (oops) |
roll onto the next iietab, but it will generate errors in the errlog at
each change, these seem to be spurious.
Marty
PS. Ive now restored the table to non partitioned and recreated the
indicies and now the insert runs w/out error.
#4
| |||
| |||
|
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.