På pgsql-general frågar Bráulio Bhavamitra:
Det här är en ganska intressant fråga. Att helt ersätta den nuvarande radbaserade butiken skulle inte vara en bra idé:det har tjänat oss extremt bra och jag är ganska säker på att det skulle vara katastrofalt prestandamässigt för OLTP-användning att ersätta den helt med en kolumnbutik.
Några kolumner. Bild med tillstånd av Yiming Sun på Flickr
Det betyder inte att kolumnbutiker är en dålig idé i allmänhet - för det är de inte. De har bara ett mer begränsat användningsfall än "hela databasen". För analytiska frågor om bifogade data är ett kolumnlager en mycket lämpligare representation än det vanliga radbaserade lagret, men alla databaser är inte analytiska.
Men för att uppnå intressanta prestandavinster behöver du göra mycket mer än att bara ändra den underliggande lagringen:du måste se till att resten av systemet kan dra nytta av den ändrade representationen, så att det kan utföra frågor optimalt; till exempel kanske du vill ha aggregat som fungerar i SIMD-läge snarare än ett värde-i-åt-gången som det är idag. Detta är i sig ett stort åtagande, och det finns andra utmaningar också.
Som det visar sig finns det ett team på 2ndQuadrant som arbetar just med dessa frågor. Vi publicerade en patch förra året, men den var inte särskilt intressant – den gjorde bara en ensiffrig procentuell förbättring av TPC-H-poängen; inte tillräckligt för att störa utvecklingssamhället med (det var ett ganska invasivt plåster). Vi vill ha mer än så.
I vår design kommer kolumnär eller inte att vara ett alternativ:du kommer att kunna säga Kära server, för det här bordet vänligen ställ in kolumnär lagring åt mig, skulle du? Tack så mycket . Och då kommer du att få en tabell som kan vara långsammare för regelbunden användning men som kommer att rocka för analyser. För de flesta av dina tabeller är den nuvarande radbaserade butiken troligen fortfarande det bästa alternativet, eftersom radbaserad lagring är mycket bättre lämpad för de mer allmänna fallen.
Vi har ingen tidsskala ännu. Håll utkik.