[BUGS] No error-checking on binary timestamp
Greetings, Based on some experimentation and reading through the code in: src/backend/utils/adl/timestamp.c ; it would appear that there's no error-checking when receiving a binary timestamp. I wouldn't care if I had figured out the binary timestamp format on the first shot but apparently I didn't and this happened: atl=> select * from a5_lan; ERROR: timestamp out of range No errors during the insert, but when I tried to select out of the table I inserted the data into that's what I got. Pretty ugly. Please fix. :) I wouldn't mind some pointers on the proper way to convert from unix time to timestamp binary format either, btw. I was attempting to do basically the same thing 'AbsoluteTimeUsecToTimestampTz', but apparently that's not right. :) Stephen signature.asc Description: Digital signature
[BUGS] BUG #1122: limit 1 doing a sequential scan
The following bug has been logged online: Bug reference: 1122 Logged by: P Buder Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: Debian Linux Description:limit 1 doing a sequential scan Details: I am actually running 7.3.6 but that isn't available on the drop down menu to report a bug so there is another bug :) When I do a select * from table limit 1 Postgresql does a sequential scan on the whole table. It should just pick one row and be done with it. The table has been analyzed but that shouldn't matter. This particular table has 4.3 million rows. Here is the explain select. book=# explain select * from imdata limit 1; QUERY PLAN -- Limit (cost=0.00..55.85 rows=1 width=152) -> Seq Scan on imdata (cost=0.00..269569.27 rows=4827 width=152) (2 rows) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1122: limit 1 doing a sequential scan
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > When I do a select * from table limit 1 > Postgresql does a sequential scan on the whole table. AFAICS you simply are misreading the EXPLAIN output. (It also sounds like you haven't vacuumed or analyzed that table in a mighty long time... if you're having performance problems that is probably the reason...) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
