> Yeah, Jeff's experiments indicated that the remaining bottleneck is lock
> management in the server. What I fixed so far on the pg_dump side
> should be enough to let partial dumps run at reasonable speed even if
> the whole database contains many tables. But if psql is taking
> AccessShareLock
Hi,
Excuse me if I was a bit rude, was not my intention. What happens is that I
think the code should be someone to do cross-platform. So many could use it.
Do you know another implementation that be cross-platform?
Thanks.
>
> De: hubert depesz lubaczewski
Hi friend,
Your function doesn't compile in Windows.
Please change it.
Thanks
>
> De: hubert depesz lubaczewski
>Para: Alejandro Carrillo
>CC: "pgsql-performance@postgresql.org"
>Enviado: Martes 29 de Mayo de 2012 16:33
>Asunto: Re: [PERFORM] Recover rows
On Mon, May 28, 2012 at 07:24:13PM +0100, Alejandro Carrillo wrote:
> ¿How I can recover a row delete of a table that wasn't vacuummed?
> I have PostgreSQL 9.1 in Windows XP/7.
http://www.depesz.com/2012/04/04/lets-talk-dirty/
Best regards,
depesz
--
The best thing about modern society is how
On Mon, 2012-05-28 at 19:24 +0100, Alejandro Carrillo wrote:
> Hi,
>
>
> ¿How I can recover a row delete of a table that wasn't vacuummed?
> I have PostgreSQL 9.1 in Windows XP/7.
The first thing to do is shut down postgresql and take a full backup of
the data directory, including any archived W
Job writes:
> i use PostgreSQL 8.4.8 on Centos 5.x and i have some table where i load with
> pg_bulkload webtraffic logs, every day.
> After loading new data, i delete with a query 30-days older logs.
Since the deletion pattern is so predictable, you should consider
setting this table up as a pa
Tatsuo Ishii writes:
> So I did qucik test with old PostgreSQL 9.0.2 and current (as of
> commit 2755abf386e6572bad15cb6a032e504ad32308cc). In a fresh initdb-ed
> database I created 100,000 tables, and each has two integer
> attributes, one of them is a primary key. Creating tables were
> resonabl
Hello,
i use PostgreSQL 8.4.8 on Centos 5.x and i have some table where i load with
pg_bulkload webtraffic logs, every day.
After loading new data, i delete with a query 30-days older logs.
Autovacuum is on.
In some systems, i experience a very huge slowdown of this table in queries,
expecially
>> We recently fixed a couple of O(N^2) loops in pg_dump, but those covered
>> extremely specific cases that might or might not have anything to do
>> with what you're seeing. The complainant was extremely helpful about
>> tracking down the problems:
>> http://archives.postgresql.org/pgsql-general
