Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I've also tried various pgbench tests, on a RAM disk and otherwise, as
well as the "table population" test I ran earlier, and don't see any
difference in performance.
I think performance is OK
Zdenek
--
Sent via pgsql-
Zdenek Kotala wrote:
I performed performance test (iGEN) on SUN x4600 with 60 concurrent
users and see result:
>
> ...
I don't see any big difference. Throughput is similar. Only response
time seems to be better with your last FSM version.
I personally happy with performance.
Thanks! I've
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Attached is a new version, now with WAL-logging of the FSM truncation. I
decided to go with the separate WAL record for that, rather than
piggybacking on the smgrtruncate's WAL record. It seems much better from
a modularity point of view t
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I'm testing this version now and I got core dump in initdb phase:
08047558 pgstat_count_heap_insert+0x20(840b120, 842d738, 80, 8047580)
Let me know if you need more info. (I'm not using fresh CVS snapshot
but two weeks old)
pgstat_coun
Heikki Linnakangas napsal(a):
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrepancy. Corruption within FSM pages is likewise fixed
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. The smgrtuncate WAL record is generated after the file is
> truncated, so there's still a small window there, where we can be left
> with a truncated main fork, but no smgrtruncate record for it, and thus
> the page of the FSM representing th
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
What's about truncate FSM during WAL replay of main fork truncation record?
That would work, except that there's no WAL record for truncating the
main fork.
Whaddya mean there's no WAL record for that? smg
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> What's about truncate FSM during WAL replay of main fork truncation record?
> That would work, except that there's no WAL record for truncating the
> main fork.
Whaddya mean there's no WAL record for that? smgrtruncate prod
Zdenek Kotala wrote:
> Heikki Linnakangas napsal(a):
>
>> It would be
>> simple to update the FSM at every heap insert and update record, but
>> that then might be an unacceptable amount of overhead at recovery. Also,
>> the index FSM is not yet updated during recovery.
>
> I expect locking pr
Zdenek Kotala wrote:
> Heikki Linnakangas napsal(a):
>> There's one known bug left. If we crash after truncating a relation, and
>> the truncation of the FSM doesn't hit the disk but the truncation of the
>> main fork does, we can end up with an FSM that shows that there's free
>> space on pages
Heikki Linnakangas napsal(a):
> It would be
> simple to update the FSM at every heap insert and update record, but
> that then might be an unacceptable amount of overhead at recovery. Also,
> the index FSM is not yet updated during recovery.
I expect locking problems specially on small tables
Simon Riggs wrote:
On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrep
On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
> Attached is a revamped version of the FSM rewrite. WAL-logging is now
> gone. Any inconsistencies between levels of the FSM is fixed during
> vacuum, and by searchers when they run into a dead end because of a
> discrepancy. Corrup
13 matches
Mail list logo
