Article View: pl.comp.bazy-danych
Article #194807Re: optymalizacja count.
From: M.M.
Date: Fri, 22 Jan 2016 21:49
Date: Fri, 22 Jan 2016 21:49
37 lines
2953 bytes
2953 bytes
On Friday, January 22, 2016 at 10:17:25 PM UTC+1, JaceK wrote: > On 22.01.2016 20:37, M.M. wrote: > > W Postgresie wolno działa mi > > > > select count(*) from table; > > > > Moim zdaniem nie powinno to działać wolno. Silnik bazy może > > sobie zliczać na bieżąco ilość rekordów i podać wyniki. Jest > > jakaś opcja do tego, aby nie pisać procedur w zdarzeniach? > > Liczba rekordów w tabeli nie jest atrybutem, który baza utrzymuje w > ramach swojej pracy (w przeciwieństwie do np. nazw i lokalizacji > indeksów, tabel, definicji ról itp. które to atrybuty są w słowniku bazy > danych). > > Oczywiście można sobie wyobrazić mechanizm, który to robi, ale z > jakiegoś powodu tego się nie implementuje - prawdopodobnie dlatego, że w > dynamicznych środowiskach i wielu tabelach baza by spędzała mnóstwo > czasu na utrzymywaniu takich "wyliczanych" informacji nieistotnych dla > poprawnego działania bazy, zamiast na obsłudze zapytań. Że nie wspomnę o > mechanizmach zapewniających odpowiedni poziom izolacji: jeden użytkownik > dostanie count(*) ze swojej sesji, a inny po wprowadzeniu dodatkowych > niezatwierdzonych jeszcze rekordów inną wartość. Utrzymywanie wielu > wartości dla wielu sesji byłoby koszmarem. > > Statystyki na tabelach są najbliższe konceptowi utrzymywania informacji > o liczbie rekordów w tabeli przez bazę. Nie są to jednak wartości > utrzymywane na bieżąco lecz gromadzone na żądanie lub w ramach > cyklicznego procesu utrzymaniowego. > > JaceK Dziękuję serdecznie za odpowiedź. Przyjmuję za pewne, że nie ma co szukać takiej 'opcji' w postgresie. Pozdrawiam
Technical Details
Message-ID:
<c68cae10-df45-405f-b391-453f1c1d3c65@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.glorb.com!h5no8131974igh.0!news-out.google.com!kr2ni6305igb.0!nntp.google.com!h5no8131968igh.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mailReferences:
<c66d991f-8f3a-4aa9-b6f6-32eb82e4d1e8@googlegroups.com> <56a29c63$0$25173$c3e8da3$e408f015@news.astraweb.com>Show Full Headers
Complete Article Headers
X-Received: by 10.66.141.102 with SMTP id rn6mr5062870pab.26.1453499360801; Fri, 22 Jan 2016 13:49:20 -0800 (PST) X-Received: by 10.182.28.129 with SMTP id b1mr102163obh.4.1453499360735; Fri, 22 Jan 2016 13:49:20 -0800 (PST) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.glorb.com!h5no8131974igh.0!news-out.google.com!kr2ni6305igb.0!nntp.google.com!h5no8131968igh.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: pl.comp.bazy-danych Date: Fri, 22 Jan 2016 13:49:20 -0800 (PST) In-Reply-To: <56a29c63$0$25173$c3e8da3$e408f015@news.astraweb.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.37.225.160; posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj NNTP-Posting-Host: 178.37.225.160 References: <c66d991f-8f3a-4aa9-b6f6-32eb82e4d1e8@googlegroups.com> <56a29c63$0$25173$c3e8da3$e408f015@news.astraweb.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <c68cae10-df45-405f-b391-453f1c1d3c65@googlegroups.com> Subject: Re: optymalizacja count. From: "M.M." <mmarszik@gmail.com> Injection-Date: Fri, 22 Jan 2016 21:49:20 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit