Itai Zukerman wrote:
In contrib/btree_gist/ I see:
CREATE FUNCTION gint4_union(bytea, internal)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE 'C';
but gint4_union does this:
INT4KEY *out = palloc(sizeof(INT4KEY));
[...]
PG_RETURN_POINTER(out);
Is the int4 return type declared above
gistPageAddItem doesn't used. Look at mail archive, it was a discussion about
keep thes or not. Shortly: gistPageAddItem suppose to recompress entry, but we
can't
find any reason to do it. One more - gistPageAddItem works only with
single-key indexes.
Itai Zukerman wrote:
In the examples I've
Send me 'x' file and I'll try to help you.
Itai Zukerman wrote:
(gdb) p (*newtup)[0]
$147 = {t_tid = {ip_blkid = {bi_hi = 0, bi_lo = 34}, ip_posid = 1}, t_info = 136}
(gdb) p (*newtup)[1]
$148 = {t_tid = {ip_blkid = {bi_hi = 65510, bi_lo = 65535}, ip_posid = 65535}, t_info
= 24575}
(gdb) p
OSDL has just come out with a set of open-source database benchmarks:
http://www.osdl.org/projects/performance/
The bad news:
This tool kit works with SAP DB open source database versions 7.3.0.23
or 7.3.0.25.
(In fact, they seem to think they are testing kernel performance, not
On the results page they list kernels like linux-2.4.18-1tier or
linux-2.4.19-rc2 or redhat-stock-2.4.7-10cmp. This sounds really like
linux-kernel-versions.
Am Montag, 3. März 2003 13:41 schrieb [EMAIL PROTECTED]:
OSDL has just come out with a set of open-source database benchmarks:
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Are we supposed to report bugs with the CVS tip of PostgreSQL, or are
we to assume that the developers are well aware of problems there and
are already working on them? After my most recent CVS update I find
that I cannot run createlang either to import the plpgsql nor the
plpython languages -
Tom Lane [EMAIL PROTECTED] writes:
[I do not see that error] here. Try a full recompile. (Unless you
configure with --enable-depend, a make distclean is a smart move
during *any* update from CVS.)
An initdb followed by rebuilding my tables fixed the problem.
--
Brandon Craig Rhodes
[EMAIL PROTECTED] writes:
I don't agree with this: XML and XHTML are two different things.
No one claimed anything to the contrary.
We could certainly upgrade the HTML portion, but I am pretty sure that
the XML standard calls for this format:
columnnamedata here/columnname
The XML
On Mon, 3 Mar 2003, Tommi Maekitalo wrote:
On the results page they list kernels like linux-2.4.18-1tier or
linux-2.4.19-rc2 or redhat-stock-2.4.7-10cmp. This sounds really like
linux-kernel-versions.
Am Montag, 3. März 2003 13:41 schrieb [EMAIL PROTECTED]:
OSDL has just come out with
We have verified this problem under both 7.3.2 and the CVS tip.
The attached example is far simpler than the actual code in our
application, but may nevertheless benefit from some explanation. We
have several tables with two ON INSERT rules:
[TABLE policy_accounts]
|
On Mon, 2003-03-03 at 07:41, [EMAIL PROTECTED] wrote:
(In fact, they seem to think they are testing kernel performance, not
database performance, which strikes me as rather bizarre. But anyway.)
That may be a terminology thing; the main SAP-DB process is called the
kernel, and it's more
-Original Message-
From: Merlin Moncure
Sent: Monday, March 03, 2003 3:47 PM
To: 'Peter Eisentraut'
Subject: RE: [HACKERS] [PATCHES] XML ouput for psql
My 0.2$: keep the xml formatting rules as simple as possible and rely on
xslt to do the document markup (going out) and schemas/xslt
On Mon, 2003-03-03 at 12:29, Neil Conway wrote:
On Mon, 2003-03-03 at 07:41, [EMAIL PROTECTED] wrote:
(In fact, they seem to think they are testing kernel performance, not
database performance, which strikes me as rather bizarre. But anyway.)
That may be a terminology thing; the main
[EMAIL PROTECTED] writes:
I don't agree with this: XML and XHTML are two different things.
No one claimed anything to the contrary.
We could certainly upgrade the HTML portion, but I am pretty sure that
the XML standard calls for this format:
columnnamedata here/columnname
The
Hey, with this new ALTER SEQUENCE patch, how about this for an idea:
I submitted a patch to always generate non-colliding index and sequence
names. Seemed like an excellent idea. However, 7.3 dumps tables like this:
CREATE TABLE blah
a SERIAL
);
SELECT SETVAL('blah_a_seq', 10);
Sort of
Hi Brandon,
Are we supposed to report bugs with the CVS tip of PostgreSQL, or are
we to assume that the developers are well aware of problems there and
are already working on them?
You're supposed to report them! If we were aware of the problems, we'd fix
them ;)
Cheers,
Chris
Brandon Craig Rhodes [EMAIL PROTECTED] writes:
The `working' test case omits the
AND (account, policy) NOT IN
(SELECT account, policy FROM policy_accounts_active)
condition from the end of executor_active, which magically makes the
executor_hamlet rule start firing as it should.
I
Tom Lane [EMAIL PROTECTED] writes:
Brandon Craig Rhodes [EMAIL PROTECTED] writes:
The `working' test case omits the
AND (account, policy) NOT IN
(SELECT account, policy FROM policy_accounts_active)
condition from the end of executor_active, which magically makes the
Brandon Craig Rhodes [EMAIL PROTECTED] writes:
If I understand your assertion, NEW does *not* in fact refer strictly
to the rows that (in this case) were INSERTed by the upstream query;
rather, NEW refers to a re-invocation - a copy or re-execution - of
the query which produced the NEW rows
Tom Lane [EMAIL PROTECTED] writes:
While rule-as-macro works beautifully for views, I've never been
entirely satisfied with it for updating queries. ... It would take a
rather fundamental redesign of the rule system to do differently,
though. Are you volunteering?
From what I have seen of
The real question is, the data collection is in real-time, but can you
have a maintenance window (6 hours a week?) to do things like REINDEX?
The database has to have the last 24 hours of data online and be acessable 24
hours a day 7 days a week 365 days a year basicly no downtime. My
Hi everyone.
Environment:
OS: UW 713
PG: 7.3.2
I've been banging my head for a few weeks on this one and could'nt find
any answer:
pg_dump is crashing with SIGSEGV before it connects to database.
I've re-compiled with --enable-debug and --enable-cassert and even that
did'nt help.
this is gdb
23 matches
Mail list logo
