🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.bazy-danych
Article #194807

Re: optymalizacja count.

#194807
From: M.M.
Date: Fri, 22 Jan 2016 21:49
37 lines
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-mail
References: <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