Hi -
This is based on a discussion I was having with neilc on IRC. He
suggested I post it here. Sorry for the length - I'm including
everything he requested.
I'm comparing the speeds of the following two queries. I was curious
why query 1 was faster than query 2:
query 1:
Select layer_nu
Hi -
This is based on a discussion I was having with neilc on IRC. He
suggested I post it here. Sorry for the length - I'm including
everything he requested
I'm comparing the speeds of the following two queries on 7.4.5. I was
curious why query 1 was faster than query 2:
query 1:
Select
I am running postgreSQL 8.0.1 under the Windows 2000. I want
to use COPY FROM STDIN function from Java application, but it doesn’t
work, it throws:
“org.postgresql.util.PSQLException: Unknown Response
Type G” error.
Please help me!
Note: COPY FROM filename works properly.
Hi,
I've downloaded the latest release (PostgreSQL 8.0) for windows.
Installation was OK, but I have tried to restore a database.
It had more than ~100.000 records. Usually I use PostgreSQL
under Linux, and it used to be done under 10 minutes.
Under W2k und XP it took 3 hours(!) Why is it so slow
The following query plans both result from the very same query run on
different servers. They obviously differ drastically, but I don't why
as one db is a slonied copy of the other with identical postgresql.conf
files.
Both databases are vacuum analyzed nightly.
Here is the query:
I've got 2 tables defined as follows:
CREATE TABLE "cluster"
(
id int8 NOT NULL DEFAULT nextval('serial'::text),
clusterid varchar(255) NOT NULL,
...
CONSTRAINT pk_cluster PRIMARY KEY (id)
)
CREATE TABLE sensorreport
(
id int8 NOT NULL DEFAULT nextval('serial'::text),
clusterid int8
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Matthew T. O'Connor wrote:
>
>> Well without thinking too much, I would first ask about your FSM
>> settings? If they aren't big enought that will cause bloat. Try
>> bumping your FSM settings and then see if you reach steady state.
>
> FSM settings a
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>
>>>I'm using ony pg_autovacuum. I expect that disk usage will reach
>>>a steady state but is not. PG engine: 7.4.5
>>
>>
>> One data point doesn't prove that you're not at a steady st
Magnus Hagander wrote:
You can *never* get above 80 without using write cache, regardless of
your OS, if you have a single disk.
Why? Even with, say, a 15K RPM disk? Or the ability to fsync() multiple
concurrently-committing transactions at once?
-Neil
---(end of broadcast
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
>>I'm using ony pg_autovacuum. I expect that disk usage will reach
>>a steady state but is not. PG engine: 7.4.5
>
>
> One data point doesn't prove that you're not at a steady state.
I do a graph about my disk usage and it's a ramp
Matthew T. O'Connor wrote:
> Well without thinking too much, I would first ask about your FSM
> settings? If they aren't big enought that will cause bloat. Try
> bumping your FSM settings and then see if you reach steady state.
FSM settings are big enough:
max_fsm_pages | 200
I wrote:
> Well, with the increased (and much more accurate) rowcount estimate,
> the estimated cost of the nestloop naturally went up a lot: it's
> proportional to the number of rows involved. It appears that the
> estimated cost of the mergejoin actually went *down* quite a bit
> (else it'd have
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I'm using ony pg_autovacuum. I expect that disk usage will reach
> a steady state but is not. PG engine: 7.4.5
One data point doesn't prove that you're not at a steady state.
> # vacuum full verbose messages;
> INFO: vacuuming "public.messages"
> INF
Gaetano Mendola wrote:
pg_class after the vacuum full for that table
relfilenode | relname | relpages | reltuples
-+--+--+-
18376 | messages |63307 | 1.60644e+06
pg_class before the vacuum full for that table
relfilenode | relname | relpages | r
[EMAIL PROTECTED] wrote:
After being a detector I found that
[EMAIL PROTECTED] ~]# rpm -qa|grep -i postgres
postgresql-7.4.5-3.1.tlc
postgresql-python-7.4.5-3.1.tlc
postgresql-jdbc-7.4.5-3.1.tlc
postgresql-tcl-7.4.5-3.1.tlc
postgresql-server-7.4.5-3.1.tlc
postgresql-libs-7.4.5-3.1.tlc
postgresql-do
Hi all,
I'm running since one week without use any vacuum full,
I'm using ony pg_autovacuum. I expect that disk usage will reach
a steady state but is not. PG engine: 7.4.5
Example:
The message table is touched by pg_autvacuum at least 2 time a day:
$ cat pg_autovacuum.log | grep VACUUM | grep
>I've downloaded the latest release (PostgreSQL 8.0) for windows.
>Installation was OK, but I have tried to restore a database.
>It had more than ~100.000 records. Usually I use PostgreSQL
>under Linux, and it used to be done under 10 minutes.
>
>Under W2k und XP it took 3 hours(!) Why is it so sl
On Tue, 22 Feb 2005 16:00:59 +0100, Vig, Sandor (G/FI-2)
<[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I've downloaded the latest release (PostgreSQL 8.0) for windows.
> Installation was OK, but I have tried to restore a database.
> It had more than ~100.000 records. Usually I use PostgreSQL
> under
> > I used you perl script and found the error =>
> > [EMAIL PROTECTED] tmp]# perl relacl.pl
> > DBI connect('dbname=template1;port=5432','postgres',...) failed: FATAL:
> IDENT
> > authentication failed for user "postgres" at relacl.pl line 21
> > Error in connect to DBI:Pg:dbname=template1;port=54
Hi,
I've downloaded the latest release (PostgreSQL 8.0) for windows.
Installation was OK, but I have tried to restore a database.
It had more than ~100.000 records. Usually I use PostgreSQL
under Linux, and it used to be done under 10 minutes.
Under W2k und XP it took 3 hours(!) Why is it so s
20 matches
Mail list logo
