On 8/6/07, Sven Clement <[EMAIL PROTECTED]> wrote:
> Ok thanks everybody for the calrification, after all now I allready learned
> something new... ;)
>
> My employer is currently thinking about migration to 8.2.x because of your
> feedback, so I think that the problem could be resolved... ;)
Note
Ok thanks everybody for the calrification, after all now I allready learned
something new... ;)
My employer is currently thinking about migration to 8.2.x because of your
feedback, so I think that the problem could be resolved... ;)
Thanks to everyone...
Sven Clement
2007/8/6, Heikki Linnakanga
Sven Clement wrote:
> Partially I found that one in the PostgreSQL Documentation for the
> 7.x.xversions under the command REINDEX where they claim that you
> should run a
> reindex under certain circumstances and for my comprehension this says that
> with some access pattern (as ours (major writes
On mán, 2007-08-06 at 00:10 -0700, Sven Clement wrote:
>
>
> 2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
> I don't remember a bug like that. Where did you read that
> from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://ww
2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
>
> I don't remember a bug like that. Where did you read that from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
Partially I found that one in the PostgreSQL Documentation for the
7.x.xversions under the command
Sven Clement wrote:
> OK so beginning on Monday I will test the config on a 8.2.x to verify the
> performance issues, but I also found some disturbing info's on the net, that
> the index may be corrupted because of the big difference between an index
> entry which is deleted and the new value inser
Hi everybody,
The bigint problem was probably a typo because I had to type the entire
definitions, as the server is on a vpn and I don't had access with my
machine where I wrote the mail, and the 7.4.2 was surely a typo... ;) I
apology...
OK so beginning on Monday I will test the config on a 8.2.
Andrew Kroeger <[EMAIL PROTECTED]> writes:
> With the table definitions you posted, one of the first things I noticed
> was that the default value for an integer column was a bigint value. I
> did some quick 32-bit math and found that the smallest legal 32-bit
> integer value is -2147483648, not -
Sven Clement wrote:
> Table: "public.tmdata"
...
> id| integer | default -2147483684::bigint
...
> Table: "public.tmdataintervalsec"
...
> id| integer | default -2147483684::bigint
Not that this directly addresses the performance issues you described,
but
Sven,
> The hardware is a IBM X306m Server, 3.2 GHz HT (Pentium IV), 1 GB RAM
> and 2x 250 GB HDD (SATA-II) with ext3 fs, one of the HDD is dedicated to
> database. OS is Debian 3.1 Sarge with PostgreSQL 7.4.7 (7.4.7-6sarge1)
> with the libpq frontend library.
Note that 7.4.7 is not the current b
Hi,
First thank you already for your answers, as we are working in an
environment with NDA's I have first to check all the queries before I may
publish them here, but the structure of the DB is publishable:
2 Tables:
Table: "public.tmdata"
Column|Type |Modifiers
--
On 3 Aug 2007 at 6:52, Sven Clement wrote:
> Hello everybody,
>
> as I'm new to this list I hope that it is the right place to post this
> and also the right format, so if I'm committing an error, I apologize
> in advance.
>
> First the background of my request:
>
> I'm currently employed by an
On Fri, 2007-08-03 at 06:52 -0700, Sven Clement wrote:
> Hello everybody,
>
> as I'm new to this list I hope that it is the right place to post this
> and also the right format, so if I'm committing an error, I apologize
> in advance.
>
> First the background of my request:
>
> I'm currently em
Hello everybody,
as I'm new to this list I hope that it is the right place to post this and
also the right format, so if I'm committing an error, I apologize in
advance.
First the background of my request:
I'm currently employed by an enterprise which has approx. 250 systems
distributed worldwid
14 matches
Mail list logo
