Re: Suggestion for optimization
От | Rod Taylor |
---|---|
Тема | Re: Suggestion for optimization |
Дата | |
Msg-id | 168a01c1dce1$679588d0$8001a8c0@jester обсуждение исходный текст |
Ответ на | Re: Suggestion for optimization ("Dann Corbit" <DCorbit@connx.com>) |
Список | pgsql-hackers |
Not to mention it only increases the speed of: SELECT count(*) FROM foo; and not: SELECT count(*) FROM foo WHERE bar; -- Rod Taylor Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Dann Corbit" <DCorbit@connx.com> Cc: "Doug McNaught" <doug@wireboard.com>; <pgsql-hackers@postgresql.org> Sent: Friday, April 05, 2002 3:21 PM Subject: Re: [HACKERS] Suggestion for optimization > "Dann Corbit" <DCorbit@connx.com> writes: > > At any rate, there is clearly a concept of cardinality in any case. > > Certainly. The count(*) value is perfectly well defined within any one > transaction. We *could*, if we wanted to, implement bookkeeping logic > that would keep track of the number of rows inserted by all transactions > and allow derivation of the count-as-seen-by-any-one-transaction at all > times. The point is that that logic would be vastly more complex than > you thought it would be; and it would not be optional. (AFAICS, the > counts would have to be determined at postmaster startup and then > maintained faithfully by all transactions. There wouldn't be any good > way for a transaction to initialize the bookkeeping logic on-the-fly --- > unless you call acquiring an exclusive lock on a table good.) No one > who's looked at it has thought that it would be a good tradeoff for > making count(*) faster. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
В списке pgsql-hackers по дате отправления: