PHP Manual
PEAR Manual
Smarty Manual
PostgreSQL
MySQL Manual
Perl Manual
Ciekawe adresy
- Polary
- Hotele Opole
- Ubezpieczenie AC
- Modelki Poznań
- Projekty
- Meble Ratanowe
- Salon Samochodowy Poznań
- Manekiny
Czytnik RSS
» Serwery Lenovo dla małych i średnich firmFirma Lenovo chce odgrywać większą rolę na rynku serwerów platformy x86, o czym świadczy fakt, że kilka dni temu wprowadziła do swojej oferty trzy serwery klasy podstawowej. Są to serwery przeznaczone dla małych i średnich firm: dwa stelażowe i jeden wolnostojący.
» AMD wypuszcza nowe roadmapy, platformia Scorpius w 2011
W Internecie pojawiły się nowe roadmapy AMD. Nową platformą będzie Leo, bazowaną na zgodnymi z przewidywaniami procesorami na jądrze Thuban, które będą sześciordzeniową wersją obecnych procesorów serii Phenom II X4. Procesory będą oparte o serwerowe odpowiedniki o nazwie kodowej Istanbul. Razem z Thubanami pojawi się chipset RD890, przewidziany jako AMD 890FX oraz mostek południowy SB850. Grafika będzie oparta o serię ATI HD 5000 DX11.
» Adobe przejmuje producenta aplikacji webowych
Koncern Adobe zgodził się wyłożyć 240 mln USD na zakup firmy Day Software Holding, specjalizującej się w tworzeniu oprogramowania webowego (głównie aplikacji z zakresu zarządzania treścią na stronach WWW oraz pracy grupowej online).
» Sygnity: kontrakt na utrzymanie Pomostu za 14 mln zł
Ministerstwo Pracy i Polityki Społecznej zawarło z Sygnity umowę na utrzymanie oprogramowania użytkowego Pomost. Przez okres dwóch lat spółka zapewni rozwój i serwis oprogramowania wraz z usługami wsparcia dla użytkowników końcowych. Wartość umowy wynosi ponad 14 mln zł brutto.
chapter 52. how the planner uses statistics
this chapter builds on the material covered in section 13.1 and section 13.2, and shows how the planner uses the system statistics to estimate the number of rows each stage in a query might return. this is a significant part of the planning / optimizing process, providing much of the raw material for cost calculation.
the intent of this chapter is not to document the code — better done in the code itself, but to present an overview of how it works. this will perhaps ease the learning curve for someone who subsequently wishes to read the code. as a consequence, the approach chosen is to analyze a series of incrementally more complex examples.
the outputs and algorithms shown below are taken from version 8.0. the behavior of earlier (or later) versions may vary.
52.1. row estimation examples
using examples drawn from the regression test database, let's start with a very simple query:
explain select * from tenk1; query plan ------------------------------------------------------------- seq scan on tenk1 (cost=0.00..445.00 rows=10000 width=244)
how the planner determines the cardinality of tenk1 is covered in section 13.1, but is repeated here for completeness. the number of rows is looked up from pg_class:
select reltuples, relpages from pg_class where relname = 'tenk1'; relpages | reltuples ----------+----------- 345 | 10000
the planner will check the relpages estimate (this is a cheap operation) and if incorrect may scale reltuples to obtain a row estimate. in this case it does not, thus:
rows = 10000
let's move on to an example with a range condition in its where clause:
explain select * from tenk1 where unique1 < 1000; query plan ------------------------------------------------------------ seq scan on tenk1 (cost=0.00..470.00 rows=1031 width=244) filter: (unique1 < 1000)
the planner examines the where clause condition:
unique1 < 1000
and looks up the restriction function for the operator < in pg_operator. this is held in the column oprrest, and the result in this case is scalarltsel. the scalarltsel function retrieves the histogram for unique1 from pg_statistics - we can follow this by using the simpler pg_stats view:
select histogram_bounds from pg_stats where tablename='tenk1' and attname='unique1'; histogram_bounds ------------------------------------------------------ {1,970,1943,2958,3971,5069,6028,7007,7919,8982,9995}next the fraction of the histogram occupied by "< 1000" is worked out. this is the selectivity. the histogram divides the range into equal frequency buckets, so all we have to do is locate the bucket that our value is in and count part of it and all of the ones before. the value 1000 is clearly in the second (970 - 1943) bucket, so by assuming a linear distribution of values inside each bucket we can calculate the selectivity as:
selectivity = (1 + (1000 - bckt[2].min)/(bckt[2].max - bckt[2].min))/num_bckts = (1 + (1000 - 970)/(1943 - 970))/10 = 0.1031
that is, one whole bucket plus a linear fraction of the second, divided by the number of buckets. the estimated number of rows can now be calculated as the product of the selectivity and the cardinality of tenk1:
rows = rel_cardinality * selectivity = 10000 * 0.1031 = 1031
next let's consider an example with equality condition in its where clause:
explain select * from tenk1 where stringu1 = 'ataaaa'; query plan ---------------------------------------------------------- seq scan on tenk1 (cost=0.00..470.00 rows=31 width=244) filter: (stringu1 = 'ataaaa'::name)
again the planner examines the where clause condition:
stringu1 = 'ataaaa'
and looks up the restriction function for =, which is eqsel. this case is a bit different, as the most common values — mcvs, are used to determine the selectivity. let's have a look at these, with some extra columns that will be useful later:
select null_frac, n_distinct, most_common_vals, most_common_freqs from pg_stats where tablename='tenk1' and attname='stringu1'; null_frac | 0 n_distinct | 672 most_common_vals | {fdaaaa,nhaaaa,ataaaa,bgaaaa,ebaaaa,moaaaa,ndaaaa,owaaaa,bhaaaa,bjaaaa} most_common_freqs | {0.00333333,0.00333333,0.003,0.003,0.003,0.003,0.003,0.003,0.00266667,0.00266667}the selectivity is merely the most common frequency (mcf) corresponding to the third mcv — 'ataaaa':
selectivity = mcf[3] = 0.003
the estimated number of rows is just the product of this with the cardinality of tenk1 as before:
rows = 10000 * 0.003 = 30
the number displayed by explain is one more than this, due to some post estimation checks.
now consider the same query, but with a constant that is not in the mcv list:
explain select * from tenk1 where stringu1 = 'xxx'; query plan ---------------------------------------------------------- seq scan on tenk1 (cost=0.00..470.00 rows=15 width=244) filter: (stringu1 = 'xxx'::name)
this is quite a different problem, how to estimate the selectivity when the value is not in the mcv list. the approach is to use the fact that the value is not in the list, combined with the knowledge of the frequencies for all of the mcvs:
selectivity = (1 - sum(mvf))/(num_distinct - num_mcv) = (1 - (0.00333333 + 0.00333333 + 0.003 + 0.003 + 0.003 + 0.003 + 0.003 + 0.003 + 0.00266667 + 0.00266667))/(672 - 10) = 0.001465
that is, add up all the frequencies for the mcvs and subtract them from one — because it is not one of these, and divide by the remaining distinct values. notice that there are no null values so we don't have to worry about those. the estimated number of rows is calculated as usual:
rows = 10000 * 0.001465 = 15
let's increase the complexity to consider a case with more than one condition in the where clause:
explain select * from tenk1 where unique1 < 1000 and stringu1 = 'xxx'; query plan ----------------------------------------------------------- seq scan on tenk1 (cost=0.00..495.00 rows=2 width=244) filter: ((unique1 < 1000) and (stringu1 = 'xxx'::name))
an assumption of independence is made and the selectivities of the individual restrictions are multiplied together:
selectivity = selectivity(unique1 < 1000) * selectivity(stringu1 = 'xxx') = 0.1031 * 0.001465 = 0.00015104
the row estimates are calculated as before:
rows = 10000 * 0.00015104 = 2
finally we will examine a query that includes a join together with a where clause:
explain select * from tenk1 t1, tenk2 t2 where t1.unique1 < 50 and t1.unique2 = t2.unique2; query plan ----------------------------------------------------------------------------------------- nested loop (cost=0.00..346.90 rows=51 width=488) -> index scan using tenk1_unique1 on tenk1 t1 (cost=0.00..192.57 rows=51 width=244) index cond: (unique1 < 50) -> index scan using tenk2_unique2 on tenk2 t2 (cost=0.00..3.01 rows=1 width=244) index cond: ("outer".unique2 = t2.unique2) the restriction on tenk1 "unique1 < 50" is evaluated before the nested-loop join. this is handled analogously to the previous range example. the restriction operator for < is scalarlteqsel as before, but this time the value 50 is in the first bucket of the unique1 histogram:
selectivity = (0 + (50 - bckt[1].min)/(bckt[1].max - bckt[1].min))/num_bckts = (0 + (50 - 1)/(970 - 1))/10 = 0.005057 rows = 10000 * 0.005057 = 51
the restriction for the join is:
t2.unique2 = t1.unique2
this is due to the join method being nested-loop, with tenk1 being in the outer loop. the operator is just our familiar =, however the restriction function is obtained from the oprjoin column of pg_operator - and is eqjoinsel. additionally we use the statistical information for both tenk2 and tenk1:
select tablename, null_frac,n_distinct, most_common_vals from pg_stats where tablename in ('tenk1', 'tenk2') and attname='unique2'; tablename | null_frac | n_distinct | most_common_vals -----------+-----------+------------+------------------ tenk1 | 0 | -1 | tenk2 | 0 | -1 |in this case there is no mcv information for unique2 because all the values appear to be unique, so we can use an algorithm that relies only on the number of distinct values for both relations together with their null fractions:
selectivity = (1 - null_frac1) * (1 - null_frac2) * min(1/num_distinct1, 1/num_distinct2) = (1 - 0) * (1 - 0) * min(1/10000, 1/1000) = 0.0001
this is, subtract the null fraction from one for each of the relations, and divide by the maximum of the two distinct values. the number of rows that the join is likely to emit is calculated as the cardinality of cartesian product of the two nodes in the nested-loop, multiplied by the selectivity:
rows = (outer_cardinality * inner_cardinality) * selectivity = (51 * 10000) * 0.0001 = 51
for those interested in further details, estimation of the number of rows in a relation is covered in src/backend/optimizer/util/plancat.c. the calculation logic for clause selectivities is in src/backend/optimizer/path/clausesel.c. the actual implementations of the operator and join restriction functions can be found in src/backend/utils/adt/selfuncs.c.
Najskuteczniejsza reklama to pozycjonowanie - Pozycjonowanie stron <= zajrzyj tu i dowiedz się więcej o pozycjonowanie stron