imitatio creatio

Rafal Pietrak asked a question about postgres performance in partitioning scenarios.

The problem is, in classical partitioning approach you decide into which partition put the data basing only on the inserted data itself.

But we consider also situation when you want to make this decision basing on current database content.

For example we have some “driving” or “routing” table which tells us which partition is currently active.

Please read the above post for more background.

I prepared 4 test cases, for all combinations of rule versus trigger and static versus dynamic aka table-driven partitioning.

Test was performed on PostgreSQL 8.3.3 on Linux, commodity desktop box.

To make things short, here are the results of two test runs (links point to test scripts):
/what is measured: INSERT of 10000 rows/

Partitioning with RULEs, no dynamic routing:
2444.293 ms 2516.314 ms

Partitioning with RULEs, with dynamic routing:
42380.037 ms 39248.666 ms

Partitioning with TRIGGER, no dynamic routing:
14512.787 ms 14669.310 ms

Partitioning with TRIGGER, with dynamic routing:
13486.808 ms 13904.370 ms

Conclusion:

If you have to do some database lookup to decide which partition data belongs to, use a trigger on master table.
If you have a well defined static set of rules, use PostgreSQL rule system.

perlre says it does not support lookbehind matches with arbitrary length.

here is a workaround


#!perl -l -w
use strict;
#
print my $txt = 'Alice has a fish. It is a nice fish.
Bob has a dog. John has a cat.
Line 3 is not important.
Filip has a perl.
---------------------------';
#
=pod WE WANT THIS but this gives Perl error.
while ( $txt =~ m{(?<=$behind_re)($match_re)(?=$ahead_re)}g ) {
print $&;
}
=cut
#
my $behind_re = qr/[A-Z][a-z]+ has a /; # Filip has a
my $match_re = qr/\w+/i; # perl
my $ahead_re = qr/\./; # .
#
while ( $txt =~ m{($behind_re)}g ) { # we look for behind match globally,
if ( $txt =~ m{\G($match_re)(?=$ahead_re)} ) { # we search for the rest anchored at each found position
print $&; # voila
}
}
#


Jarek napisał ciekawy artykuł o sortowaniu napisów w PostgreSQL (i nie tylko, w zasadzie rzecz dotyczy localesów w glibc).

Ciekawostka dla administratorów systemów z serii win2k/xp/itd itp.

Mamy sobie jakiegoś batcha:

C:\Temp>more test.cmd
@echo off
echo before sleep
c:\cygwin\bin\sleep 60
echo after sleep


I sobie go uruchamiamy.

C:\Temp>test.cmd
before sleep


Otwieramy drugi terminal, a w nim

C:\Temp>echo echo this was added after script was started >> test.cmd


Wracamy do pierwszego okienka i czekamy cierpliwie.


C:\Temp>test.cmd
before sleep
after sleep
this was added after script was started


życie jest pełne niespodzianek.

aha. jako ćwiczenie dla chętnych zostawiam sprawdzenie co się stanie, jesli zamiast dopisywać na koniec, dopiszemy np. 10 pustych linijek w środku skryptu :)

bluszcz napisał ciekawy opis kodu linuksowego OOM killera.

Zaciekawiony tematem pokopałem trochę i okazuje się co następuje:

W jednej ze starszych wersji jądra można było go w ogóle wyłączyć.

W 2.6.x z tego co widzę nie ma takiej możliwości.

Za to można wyłączać oom killer per proces!!!

Są sobie albowiem (przynajmniej w 2.6.21 które akurat mam pod ręką) pseudopliki:

/proc/<pid>/oom_score — tu można podejrzeć aktualny badness score dla procesu,
oraz
/proc/<pid>/oom_adj - tu można sterować wysokością badness score :)

Dozwolone wartości to liczby całkowite z zakresu [-17,+15]. Wysoka wartość to większe prawdopodobieństwo zabicia.


/*
* Adjust the score by oomkilladj.
*/
if (p->oomkilladj) {
if (p->oomkilladj > 0)
points <<= p->oomkilladj;
else
points >>= -(p->oomkilladj);
}


Wartość -17 jest magiczna o tyle że blokuje w ogóle możliwość zabicia procesu przez oom killer.

if (p->oomkilladj == OOM_DISABLE)
continue;


Zatem nasz zabójca ma słaby punkt.

Stosować z umiarem!