Re: [HACKERS] v6.4 - What is planned...?

Bruce Momjian wrote:
>
> > 6. Transaction manager: get rid of pg_variable; do not prefetch
> > XIDs; nested transactions; savepoints.
>
> That's quite a list.
>
> Vadim, I hate to ask, but how about the buffering of pg_log writes and
> the ability to do sync() every 30 seconds then flush pg_log, so we can
> have crash reliability without doing fsync() on every transaction.
>
> We discussed this months ago, and I am not sure if you were thinking of
> doing this for 6.4. I can send the old posts if that would help. It
> would certainly increase our speed vs. fsync().

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...

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...

Vadim