2009/2/20 Tena Sakai :
> Hi Everybody,
>
> Here's the query (please read them in fixed-size font, if
> you can):
>
> select subjectid, genotype.markerid, a1.value as allele1,
> a2.value as allele2, genotype.dateCreated,
> genotype.dateReplaced, genotype.ignore,
> genotype.i
I don't have too much delete and update in the middle of the day to run
autovacuum, but in the night, before vacuum analyze, there is some proccess
that does delete and update, then run vacuum analyze.
On Thu, Feb 19, 2009 at 5:11 PM, Scott Marlowe wrote:
> On Thu, Feb 19, 2009 at 11:01 AM, Rafae
We run into the following issue with Windows 2003 and Postgres 8.2.6
while database was running:
FATAL: "pg_tblspc/16405/37638" is not a valid data directory
DETAIL: File "pg_tblspc/16405/37638/PG_VERSION" is missing.
ERROR: could not open relation 16405/37638/2661: No such file or
d
On Fri, Feb 20, 2009 at 03:32:16PM +0100, Nicola Mauri wrote:
>
> We run into the following issue with Windows 2003 and Postgres 8.2.6 while
> database was running:
>
> FATAL: "pg_tblspc/16405/37638" is not a valid data directory
> DETAIL: File "pg_tblspc/16405/37638/PG_VERSION" is missing.
On Fri, Feb 20, 2009 at 7:32 AM, Nicola Mauri wrote:
>
> We run into the following issue with Windows 2003 and Postgres 8.2.6 while
> database was running:
>
> FATAL: "pg_tblspc/16405/37638" is not a valid data directory
> DETAIL: File "pg_tblspc/16405/37638/PG_VERSION" is missing.
> ERROR:
Hi Emanuel,
> Do you tried partitioned tables? diferent tablespaces?
> set the storage external for more important columns?
> what kind of indexes do you have?
I think the table design is ok.
I don't know what "set the storage external" means.
Maybe you can explain it to me in lay-person's terms?
2009/2/20 Tena Sakai :
> Hi Emanuel,
>
>> Do you tried partitioned tables? diferent tablespaces?
>> set the storage external for more important columns?
>> what kind of indexes do you have?
>
> I think the table design is ok.
Sorry, copy to the list.
The table desing is ok. Partitioned tables is
Hi there,
I'm going to pg_restore a database dump of about 220 GiB (uncompressed,
but most data is BLOBs). The machine has 8 GiB of memory and 8 cores.
Is there any advice to speed up restoring, postgresql.conf-wise?
I already have a script which does the data loading and index creation
in parall
Hi Scott,
> What does explain and (it'll take a while to get
> it) explain analyze select ... have to say?
Here's what "explain select..." told me:
canon=# explain select subjectid, genotype.markerid, a1.value as allele1,
canon-# a2.value as allele2, genotype.dateCreated,
canon-#
On Friday 20 February 2009, Tena Sakai wrote:
> Hi Scott,
>
> > What does explain and (it'll take a while to get
> > it) explain analyze select ... have to say?
>
> ---
>-- Hash Join (cost=165264.65..55486119.31 rows=
Tino Schwarze a écrit :
> [...]
> I'm going to pg_restore a database dump of about 220 GiB (uncompressed,
> but most data is BLOBs). The machine has 8 GiB of memory and 8 cores.
> Is there any advice to speed up restoring, postgresql.conf-wise?
>
> I already have a script which does the data loadi
11 matches
Mail list logo
