> I never forgot about this :)
> Ok, but let's wait ~ Aug 1st: I'm not sure that I'll have
> time for 6. and delayed fsync implemetation depends on
> design of transaction manager...
Thanks. Makes sense.
>
> BTW, I have another item:
>
> 7. Re-use transaction XID (no commit --> no fsync) of read only
> transactions (SELECTs could be left un-commited!).
>
> And more about performance of sequential scans:
> as you know HeapTupleSatisfies can perfome scan key test and
> so bypass expensive HeapTupleSatisfiesVisibility test for
> unqualified tuples ... but this ability is never used by
> SeqScan!!! ALL visible tuples are returned to top level
> ExecScan and qualified by ExecQual - this is very very bad.
> SeqScan should work like IndexScan: put quals from WHERE into
> ScanKey-s for low level heap scan functions (it's now
> possible for ANDs but could be extended for ORs too)...
>
> Another issue - handling of functions with constant args
> in queries - for query
>
> select * from T where A = upper ('bbb')
>
> function upper ('bbb') will be executed for each tuple in T!
> More of that - if there is index on T(A) then this index will
> not be used for this query!
> Obviously, upper ('bbb') should be executed (by Executor, not
> parser/planner) once: new Param type (PARAM_EXEC) implemented
> for subselects could help here too...
I see what you are saying.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)