Folks,
Please find enclosed a patch that shows how to get a quick
approximation of count(*) on a table.
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Index: doc/src/sgml/func.sgml
===
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Here's a PL/Python patch that includes a few tests for Universal
> Newline Support.
Applied to HEAD and 8.0 branch.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checke
David Fetter <[EMAIL PROTECTED]> writes:
> Please find enclosed a patch that shows how to get a quick
> approximation of count(*) on a table.
I'm not sure we should be encouraging people to look at reltuples...
for one thing, it's deliberately a moving average under 8.0.
r
On Thu, Mar 24, 2005 at 12:34:51PM -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > Please find enclosed a patch that shows how to get a quick
> > approximation of count(*) on a table.
>
> I'm not sure we should be encouraging people to look at reltuples...
> for one thing, it
Manuel Baena García wrote:
> El mi?, 23-03-2005 a las 17:07 -0500, Bruce Momjian escribi?:
> > Are you saying your script has all the functionality of dbf2pg.c? It
> > doesn't seem possible.
>
> No, I'm not saying it. By example, my script doesn't connect to a pg db,
> I prefer to use a pipe. My
You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
is used. That breaks anything that requires position-independent code
... for instance ecpglib.
regards, tom lane
---(end of broadcast)---
TIP 1: subscr
Tom Lane wrote:
> You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
> is used. That breaks anything that requires position-independent code
> ... for instance ecpglib.
Strange because it worked on my BSD system and I do compile ecpg. What
do you suggest? Is this worth fixi
Bruce Momjian writes:
> Tom Lane wrote:
>> You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
>> is used. That breaks anything that requires position-independent code
>> ... for instance ecpglib.
> Strange because it worked on my BSD system and I do compile ecpg. What
> do
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
> >> is used. That breaks anything that requires position-independent code
> >> ... for instance ecpglib.
>
> > Strange because it worked on my BSD system and
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you should leave the $(libpq) macro alone and add a $(libpgport)
>> macro ... and yes, you will have to go around and modify the client
>> program Makefiles individually.
> How is this? It creates a new $(libpq_only) for library usage.
> ecpgli
This patch updates psql and pg_dump to use the new copy api. Probably
needs some review.
I have tested it with dos and unix newlines, etc.
Chris
? src/bin/initdb/.deps
? src/bin/initdb/initdb
? src/bin/ipcclean/ipcclean
? src/bin/pg_config/.deps
? src/bin/pg_config/pg_config
? src/bin/pg_control
The attached patch allows EXPLAIN ANALYZE to break out the time spent in
triggers when EXPLAINing a statement that can fire triggers. Formerly
this time was included in "Total runtime" but not otherwise accounted
for.
An example is
regression=# explain analyze delete from foo;
The attached patch allows EXPLAIN ANALYZE to break out the time spent in
triggers when EXPLAINing a statement that can fire triggers. Formerly
this time was included in "Total runtime" but not otherwise accounted
for.
Very nice.
An example is
regression=# explain analyze delete from foo;
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Could we get plain EXPLAIN output as well:
Plain EXPLAIN doesn't run the query, and therefore not the triggers.
> Also, have you considered statement level triggers?
I haven't actually tested that case, but I believe they'll show up
if used.
Could we get plain EXPLAIN output as well:
Plain EXPLAIN doesn't run the query, and therefore not the triggers.
But the point of it is to estimate, right? Could it not estimate the
number of time each trigger would be called. Surely that's the same as
estimating the number of rows each clause w
Right. So what's the point? It seems like the printout would just be
useless noise: it'd repeat N times the estimate of the top-level number
of output rows.
Well I guess the point would be to remind people that there are
(potentially) expensive triggers that will run, so even though the
analysi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Plain EXPLAIN doesn't run the query, and therefore not the triggers.
> But the point of it is to estimate, right? Could it not estimate the
> number of time each trigger would be called. Surely that's the same as
> estimating the number of
The attached patch allows EXPLAIN ANALYZE to break out the time spent in
triggers when EXPLAINing a statement that can fire triggers. Formerly
this time was included in "Total runtime" but not otherwise accounted
for.
Actually, should you make it talk about RULEs as well?
Chris
---
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Right. So what's the point? It seems like the printout would just be
>> useless noise: it'd repeat N times the estimate of the top-level number
>> of output rows.
> Well I guess the point would be to remind people that there are
> (potentia
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Actually, should you make it talk about RULEs as well?
No, because the presented plan is post-RULE-expansion.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe
20 matches
Mail list logo
