Iostat

Interpretacja wyników Iostat za postem ....

Wynik polecenia iostat-dmx /dev/sda1 3
util% - im wyższy - tym gorzej , znaczy że dysk jest mocno zutylizowany (duży ruch I/O). Jesli ciągle przekracza 80% należy rozważyć rozbudowę/zmianę RAID
w/s - zapisy na sekundę
r/s  - odczyty na sekundę
svctm - czas obsługi requesta zapisu lub odczytu. Im większa wartość tym gorzej, znaczy że system ma długi czas obsługi requesta :(((

Powyższe wartości składają się na wyliczenie UTIL% = (r/s + w/s) * svctim / 1000ms * 100
---------------------------------------------------------------

• (await-svctim)/await*100: The percentage of time that IO operations spent waiting in queue in comparison to actually being serviced. If this figure goes above 50% then each IO request is spending more time waiting in queue than being processed. If this ratio skews heavily upwards (in the >75% range) you know that your disk subsystem is not being able to keep up with the IO requests and most IO requests are spending a lot of time waiting in queue. In this scenario you will again need to take any of the actions above
• %iowait: This number shows the % of time the CPU is wasting in waiting for IO. A part of this number can result from network IO, which can be avoided by using an Async IO library. The rest of it is simply an indication of how IO-bound your application is. You can reduce this number by ensuring that disk IO operations take less time, more data is available in RAM, increasing disk throughput by increasing number of disks in a RAID array, using SSD (Check my post on Solid State drives vs Hard Drives) for portions of the data or all of the data etc

Timestamp (0/2/4/8)

'Przedruk' z http://www.postgres.cz/index.php/PostgreSQL_SQL_Tricks

Dropping milliseconds from timestamp

Usually we don't need timestamp value in maximum precision. For mostly people only seconds are significant. Timestamp type allows to define precision - and we could to use this feature:

postgres=# select current_timestamp;
             now              
------------------------------
 2009-05-23 20:42:21.57899+02
(1 row)

Time: 196,784 ms
postgres=# select current_timestamp::timestamp(2);
          now           
------------------------
 2009-05-23 20:42:27.74
(1 row)

Time: 51,861 ms
postgres=# select current_timestamp::timestamp(0);
         now         
---------------------
 2009-05-23 20:42:31
(1 row)

Time: 0,729 ms

Binary casting

Bo zawsze zapominam, a już nie raz potrzebowałem...
...cytat z oficjalnej dokumentacji ...

Table 9.10. Bit String Operators

Operator	Description	Example	Result
||	concatenation	B'10001' || B'011'	10001011
&	bitwise AND	B'10001' & B'01101'	00001
|	bitwise OR	B'10001' | B'01101'	11101
#	bitwise XOR	B'10001' # B'01101'	11100
~	bitwise NOT	~ B'10001'	01110
<<	bitwise shift left	B'10001' << 3	01000
>>	bitwise shift right	B'10001' >> 2	00100

The following SQL-standard functions work on bit strings as well as character strings: length, bit_length, octet_length, position, substring.
In addition, it is possible to cast integral values to and from type bit. Some examples:

44::bit(10)                    0000101100
44::bit(3)                     100
cast(-44 as bit(12))           111111010100
'1110'::bit(4)::integer        14

Note that casting to just “bit” means casting to bit(1), and so it will deliver only the least significant bit of the integer.

VM Ware ESXi resource allocation

Zapisuję żeby pamiętać czego się spodziewać po odpowiednich ustawieniach
PostgreSQL Server 8.2 na VMWareESXi 4.x
- HDD  clustra PG - Mode Independent,Persistent (Changes are immediately and permanently written to the disk)
- Resource 
-- CPU =2 core 4522MHz +Shares=HIGH +Reservation=4522MHz +Limit=Unlimited
-- Memory 4096MB +Shares=HIGH +Reservation=4096MB +Limit=Unlimited

Dla ciężkiego selecta:

iostat -m -d /dev/sdb1 1  

Odczyt rzędu 45 - 100 MB

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb1            361,00        42,54         0,00         42          0

 iostat -x -d /dev/sdb1 2

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdb1            151,00     0,00  350,00    0,00 84816,00     0,00   242,33     1,05    2,94   2,14  74,80

Zapis DDL z EMS PostgreSQL Manager

1. Opis dla EMS 2010 ver 4.6.0.3
Zapis DDL wykonuj ZAWSZE w kodowaniu != UNICODE(USC-2) oraz UNICODE(UTF-8)

psql nie potrafi zinterpretować żadnego z nich!!!!

Dodanie set client_encoding = 'UNICODE' nie załatwia sprawy
2. Jedyną możliwością jest wybranie Charset 'cp1250(Windows CentralEuropean)
3. Można również skopiować do schowka (Ctrl+C), a następnie utworzenie pliku
- na windowsie edytory tworzą standardowo w kodowaniu ANSI (czyli win1250)
wówczas dla spokoju sumienia dodajemy na początku

set client_encoding = 'WIN1250'

----
Ewentualnie zapisujemy plik w UTF-8 (wybierając w edytorze) wówczas koniecznie musimy dodać
set client_encoding = 'UNICODE';