The following works for Gentoo Linux (my binaries are currently in
/usr/local/sbin/):
/etc/init.d/dbmail-imapd
#!/sbin/runscript
# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Publi
At 04:29 PM 20/11/2002 +0100, Roel Rozendaal - IC&S wrote:
dbmail=> explain SELECT messageblk FROM messageblks WHERE message_idnr =
100::bigint ORDER BY messageblk_idnr limit 1;
\
Limit (cost=0.00..777.50 rows=1 width=40)
-> Index Scan using messageblks_id_idx on messageblks
(cost=0.00..1129
I received the following error using the sql/mysql/create_tables.mysql
file to create the mysql db & tables:
> mysql -u root -p more VERSION
$Id: VERSION,v 1.1 2002/10/12 22:21:29 eelco Exp $
This is DBMAIL version 1RC4.
Thanks,
John
--
"Shortcuts Make For Long Delays" -J.R.R Tolken
Hi Richard,
It is our intent to write dedicated code for each database (this is
actually not too much work, we've done the postgresql driver in a few
days). ODBC is really slow and can't utilize specific features of a
database to the most extend.
Best regards,
Eelco
On woensdag, nov 20, 20
Hi john,
this bug is known and a patch has been supplied, i just forgot to place
it into cvs. fixing it right now!
regards roel
John Ruff heeft op donderdag, 21 nov 2002 om 05:49 (Europe/Amsterdam)
het volgende geschreven:
I received the following error using the sql/mysql/create_tables
It seems pretty much bigint to me :)
Indeed i was reluctant to remove the LIMIT clause but it seems for now
that there is no other option. There hasn't been any ANALYZE statements
at all (we migrated this db from another one and encountered the
problem afterwards); but quite frankly i would
On Wed, 20 Nov 2002 15:43:50 -0500
Jacques Beaudoin <[EMAIL PROTECTED]> wrote:
> Any idea where to look
> to get postfix to work
>
>
> Nov 20 15:37:28 mail1 postfix/smtpd[1939]: connect from
> unknown[10.115.1.22]
> Nov 20 15:37:28 mail1 postfix/smtpd[1939]: 27FB81474
At 09:18 AM 21/11/2002 +0100, Roel Rozendaal - IC&S wrote:
Below is output describing messageblks table, all indices and finally
the two messageblk indices.
Any chance you could tell me the version of PostgreSQL you are running?
---
We encountered this problem using version 7.2.3; i just checked on my
mac and version 7.2.1 has the same EXPLAIN output.
Philip Warner heeft op donderdag, 21 nov 2002 om 10:48
(Europe/Amsterdam) het volgende geschreven:
At 09:18 AM 21/11/2002 +0100, Roel Rozendaal - IC&S wrote:
Below is out
At 09:18 AM 21/11/2002 +0100, Roel Rozendaal - IC&S wrote:
There hasn't been any ANALYZE statements
at all (we migrated this db from another one and encountered the
problem afterwards); but quite frankly i would still regard it as a bug
if i need to run an ANALYZE statement first for such a simpl
At 11:12 AM 21/11/2002 +0100, Roel Rozendaal - IC&S wrote:
We encountered this problem using version 7.2.3; i just checked on my mac
and version 7.2.1 has the same EXPLAIN output.
I'm still trying to understand this behaviour. Has the messageblks table
been vacuumed recently? In the case of th
Well the odd thing in my opinion is the fact that the explain shows the
same query plan in both installations while the data in the database is
_very_ different. On my mac, the installation was just for trying to
port dbmail to OS X. The database contains 6 messages making a total
size of 220 b
At 02:58 PM 21/11/2002 +0100, Roel Rozendaal - IC&S wrote:
On my mac, the installation was just for trying to port dbmail to OS X.
The database contains 6 messages making a total size of 220 bytes for 1
user; no updates or changes.
This is not necessarily odd; on an empty database it may well
At 01:05 AM 22/11/2002 +1100, Philip Warner wrote:
I have confirmed that I get the same strategy as you on an empty DB; I
think you should run an ANALYZE then try the query again. We run an
analyze every night.
I should point out that as of recent versions of PG (7.1?), ANALYZE is a
lot cheap
Hi Philip,
For what i know a LIMIT instruction should never result in a different
query execution scheme. A limit is always a query result subset and
will never involve the actual query itself. Subsequently analyze won't
be able to optimize anything because a query with limit clause cannot
be
At 03:20 PM 21/11/2002 +0100, Eelco van Beek - IC&S wrote:
For what i know a LIMIT instruction should never result in a different
query execution scheme. A limit is always a query result subset and will
never involve the actual query itself. Subsequently analyze won't be able
to optimize anythi
I just discussed this with Roel which refreshed some extra information.
The result subset (a LIMIT clause) als always known to the scanner
because it may need to return only one or a few tuples. Fact of the
matter is that it will not change the way of which the information is
actually retrieved
At 03:30 PM 21/11/2002 +0100, Eelco van Beek - IC&S wrote:
Fact of the matter is that it will not change the way of which the
information is actually retrieved.
As I said - you are wrong here. Perhaps our emails crossed. Version 7.0 of
PG introduced the ability to use fast-start plans for just
This patch fixes it so you must specify either --with-mysql or
--with-pgsql otherwise it will not build (since you must have a database
backend). Patched against 11/21/2002 CVS.
Patch is attached and all my patches are available on
http://dbmail.adiis.net
automake was also re-run to update the M
My dbmail test setup in now UP
Is somebody working on a webmin administration tool for dbmail.
Or a KDE administration tool
Thanks
20 matches
Mail list logo
