On Jan 18, 2004, at 1:34 AM, Christopher Kings-Lynne wrote:
Theory B would be that there's some huge overhead in calling
non-built-in
functions on your platform. We do know that looking up a "C"
function is
significantly more expensive than looking up a "builtin" function,
but
there should onl
Theory B would be that there's some huge overhead in calling non-built-in
functions on your platform. We do know that looking up a "C" function is
significantly more expensive than looking up a "builtin" function, but
there should only be half a dozen such calls involved in this test case;
it's ha
On Jan 17, 2004, at 11:33 PM, Tom Lane wrote:
The difference between "total runtime" and the top plan node's runtime
has to represent plan startup/shutdown time. I'm suspicious that your
stubs are somehow not initializing something, though on first glance I
do not see what.
I can't see anything ei
On Jan 17, 2004, at 11:27 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
costestimate: {
PG_RETURN_VOID();
}
This at least needs to set some values into the output parameters ---
zeroes are okay, not setting them at all isn't. I'm surprised the
planner doesn't go nuts. It loo
Eric Ridge <[EMAIL PROTECTED]> writes:
> I should have included the entire explain output:
> stub AM:
> Index Scan using idxa_stub on test2 (cost=0.00..2.68 rows=1 width=5)
> (actual time=0.002..0.002 rows=0 loops=1)
> Index Cond: (a ==> '1'::text)
> Total runtime: 0.247 ms
> builtin bt
Eric Ridge <[EMAIL PROTECTED]> writes:
> costestimate: {
> PG_RETURN_VOID();
> }
This at least needs to set some values into the output parameters ---
zeroes are okay, not setting them at all isn't. I'm surprised the
planner doesn't go nuts. It looks from your EXPLAIN results like
the valu
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
I've created a stub AM that literally does nothing.
It's not possible for an index AM to "do nothing", at least not for an
indexscan. It has to return tuple pointers. What are you doing for
that?
I should have i
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
I've created a stub AM that literally does nothing.
It's not possible for an index AM to "do nothing", at least not for an
indexscan. It has to return tuple pointers. What are you doing for
that?
costestimate: {
Eric Ridge <[EMAIL PROTECTED]> writes:
> I've created a stub AM that literally does nothing.
It's not possible for an index AM to "do nothing", at least not for an
indexscan. It has to return tuple pointers. What are you doing for
that?
regards, tom lane
---
I've created a stub AM that literally does nothing. It indexes
nothing. It scans for nothing. Nadda. It does just enough work to
specify return values that prevent PG from dumping core.
What I've found is that this stub AM, compiled with the same options as
postgres itself (-O2 -fno-strict-
[EMAIL PROTECTED] ("PostgreSQL Bugs List") writes:
> Description:Configuration should be in /etc/postgres
>
> Details:
>
> It would be better if postgres kept the configurations files in
> standard /etc location. Like under /etc/postgres
This "fix" would prevent people from having multipl
Mensaje citado por David Garamond <[EMAIL PROTECTED]>:
> Marc G. Fournier wrote:
> >>From the Firebird FAQ:
> >
> > "The first beta was released on January 29, 2003. We are hoping to be
> > close to a full release some time around Easter 2003."
> >
> > They are at RC8 right now ... running a *we
12 matches
Mail list logo
