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 *wee* bit behind
[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 multiple
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
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
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: {
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
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 values
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 btree AM:
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
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
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 hard
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 only
12 matches
Mail list logo
