Alvaro Herrera wrote:
andy wrote:
with autovacuum enabled with default settings, cramd.sql is 154M:
[EMAIL PROTECTED]:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
real3m43.687s
[...]
Now I dropdb and disable autovacuum, restart pg:
[EMAIL PROTECTED]:/pub/back$ time ( pg_res
Alvaro,
On 11/2/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Even though the restore times are very similar, I find it a bit
> disturbing that the "CREATE INDEX" is shown to be waiting. Was it just
> bad luck that the ps output shows it that way, or does it really wait
> for long?
I did the t
On Fri, 02 Nov 2007 15:20:27 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > My question is -hackers, is who wants first bite and what do they
> > want :)
>
> Something I'd like to have back real soon is the daily DBT run against
> CVS HEAD that Mark
Pavel Stehule wrote:
> On 01/11/2007, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > > When I try manually rebuild cluster I had second problem:
> >
> > > C:\PostgreSQL\bin>initdb -D ../data
> > > The program "postgres" is needed by initdb but was not found
Jeff Amiel wrote:
>
> Bruce Momjian wrote:
>>>
>>> No, it isn't. Please add a TODO item about it:
>>> * Prevent long-lived temp tables from causing frozen-Xid advancement
>>>starvation
>
> Can somebody explain this one to me? because of our auditing technique, we
> have many LONG lived temp
andy wrote:
>
> with autovacuum enabled with default settings, cramd.sql is 154M:
>
> [EMAIL PROTECTED]:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
>
> real3m43.687s
[...]
> Now I dropdb and disable autovacuum, restart pg:
>
> [EMAIL PROTECTED]:/pub/back$ time ( pg_restore -Fc -C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 02 Nov 2007 17:11:30 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Yeah, I'd vote for people just building private PG installations in
> >> their own home
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Yeah, I'd vote for people just building private PG installations in
>> their own home directories. I am not aware of any performance-testing
>> reason why we'd want a shared installation, and given that people a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 02 Nov 2007 15:37:17 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> > Just a follow-up to note that Red Hat has graciously donated a 1
> > year RHEL subscription and myYearbook is paying Command Prompt
Hello,
> You seem not to have understood my recommendation to use a
> callback function. This patch might work nicely for SQL
> functions but there will be no good way to use it for
> plpgsql, or probably any other PL function language. If
> we're going to change the parser API then I'd like
Hi,
Le Friday 02 November 2007 21:08:24 Tom Lane, vous avez écrit :
> No, foreign-key triggers always have names too, and they don't look like
> that (they look like RI_ConstraintTrigger_nnn). I cannot find anyplace
> in PG that supplies "" as a default name for a trigger, either.
> So there's so
[EMAIL PROTECTED] writes:
> All triggers in the schema are named. So I assume they are triggers for
> foreign keys.
No, foreign-key triggers always have names too, and they don't look like
that (they look like RI_ConstraintTrigger_nnn). I cannot find anyplace
in PG that supplies "" as a default n
[EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007, Heikki Linnakangas wrote:
Date: Fri, 02 Nov 2007 18:11:14 +
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list
Subject: Re: [HACKERS] should I worry?
[EMAIL PROTECTED] wrote:
I'm now testing 8.3beta2 on a
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> On 02/11/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Exactly same problem !! I use postgres V 8.2.4 on windows vista.
>> Have you found a response since ?
>>
> use runas and run initdb as user postgres
Doesn't sound like that will fix it.
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> Just a follow-up to note that Red Hat has graciously donated a 1 year
> RHEL subscription and myYearbook is paying Command Prompt to setup the
> RHEL box for community use.
Sorry that Red Hat was so slow about that :-(
> [ various interesting questions
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> My question is -hackers, is who wants first bite and what do they
> want :)
Something I'd like to have back real soon is the daily DBT run against
CVS HEAD that Mark Wong was doing at OSDL. Maybe we don't need a
particularly enormous machine for th
On 11/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> > The feature i am talking about is very simple and it won't even add
> > 100 lines of code into the Postgres source code base.
>
> [ splorfff... ] The grammar support alone will cost ten ti
On 02/11/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 1 nov, 19:30, [EMAIL PROTECTED] (Tom Lane) wrote:
> > "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > > When I try manually rebuild cluster I had second problem:
> > > C:\PostgreSQL\bin>initdb -D ../data
> > > The program "postgres" i
Just a follow-up to note that Red Hat has graciously donated a 1 year
RHEL subscription and myYearbook is paying Command Prompt to setup the
RHEL box for community use.
We've not worked out a scheduling methodology, or how to best organize
the use of said hardware, but I know that Tom and others a
On Fri, 2 Nov 2007, Heikki Linnakangas wrote:
> Date: Fri, 02 Nov 2007 18:11:14 +
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] should I worry?
>
> [EMAIL PROTECTED] wrote:
> > I'm now testing 8.3beta2 on a relatively
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> On 11/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> [ splorfff... ] The grammar support alone will cost ten times that.
> But i guess(I may be wrong), you may be wrong about the grammar support
> part.
Well, a crude estimate is that SELECT
On 1 nov, 19:30, [EMAIL PROTECTED] (Tom Lane) wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > When I try manually rebuild cluster I had second problem:
> > C:\PostgreSQL\bin>initdb -D ../data
> > The program "postgres" isneededbyinitdbbutwas not found in the
> > same directory as "C:\Postg
[EMAIL PROTECTED] wrote:
I'm now testing 8.3beta2 on a relatively big (10G) database.
I've tried with pg_dymp -Fc/pg_restore and pg_dump/pgsql and get those
errors:
Could you be a bit more specific? The database you tried to restore to
was empty, right? Can you post the dump file (schema-only)
Hi hackers,
I'm now testing 8.3beta2 on a relatively big (10G) database.
I've tried with pg_dymp -Fc/pg_restore and pg_dump/pgsql and get those
errors:
ERROR: trigger "" for relation "objets" already exists
ERROR: trigger "" for relation "perso_objets" already exists
ERROR: trigger "" for rela
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
A BEFORE UPDATE trigger would be better, and probably hardly more
expensive than a wired-in facility (especially if you were willing to
write it in C).
Yes. I also prefer the trigger idea to a rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
The test lab is finally starting to come to fruition. We (the
community) have been donated hardware via MyYearbook and Hi5. It is my
understanding that we may also have some coming from HP.
We are currently setting up a Trac for management and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A BEFORE UPDATE trigger would be better, and probably hardly more
>> expensive than a wired-in facility (especially if you were willing to
>> write it in C).
> Yes. I also prefer the trigger idea to a rule because triggers are easy
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
>> Another reason is that it avoids the whole problem of updating multiple
>> pages atomically, without deadlocks.
>
>
> Thanks Heikki. I am still not getting what you said. In the case of HOT,
> you need to update the top pointer to point
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
At the moment I have to write things like:
update tname set foo = bar ... where foo is null or foo <> bar
One way I've done this is make RULEs which
Gokulakannan Somasundaram wrote:
Thanks Heikki. I am still not getting what you said. In the case of HOT,
you need to update the top pointer to point to some other tuple in some
other page. That's one update. what's the other one?
say currently the top of heap chain points to (2,3) . Imagine we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 2 Nov 2007 22:33:16 +0530
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> wrote:
>
>
> Tom,
>If you have made this comment, when i requested for the
> comment, i would have dropped this idea there itself. :). But please
> let me know
On Fri, Nov 02, 2007 at 10:27:27PM +0530, Gokulakannan Somasundaram wrote:
> say currently the top of heap chain points to (2,3) . Imagine we are making
> the HOT chain through the pages. there might be a situation it should start
> pointing to (4,5) after the tuple at (2,3) gets ready to be Vacuum
On 11/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> > The feature i am talking about is very simple and it won't even add
> > 100 lines of code into the Postgres source code base.
>
> [ splorfff... ] The grammar support alone will cost ten
On 11/2/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > I understand that if you have to Vacuum a tuple, it has to satisfy the
> > necessary snapshot requirements. i will never be able to reduce the
> chain to
> > just one, because the there is always a in
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> The feature i am talking about is very simple and it won't even add
> 100 lines of code into the Postgres source code base.
[ splorfff... ] The grammar support alone will cost ten times that.
You should probably reflect on the fact that n
David Fetter <[EMAIL PROTECTED]> writes:
> On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
>> At the moment I have to write things like:
>>
>> update tname set foo = bar ... where foo is null or foo <> bar
> One way I've done this is make RULEs which basically drop non-updating
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 2 Nov 2007 08:40:46 -0400
Jeff Trout <[EMAIL PROTECTED]> wrote:
> Hey folks,
>
> Asking here since it may deal with clever things such as alignment
> and or binary reps.
>
> I'm migrating from some opterons to some xeons (E5345) both are
On 11/2/07, Hans-Juergen Schoenig <[EMAIL PROTECTED]> wrote:
>
>
> I think Simon Riggs is already working on that idea. This one is fairly
> easy to implement. I think these are some of the features only a time-stamp
> based database can implement. I think database standards were formed during
> th
Gokulakannan Somasundaram wrote:
I understand that if you have to Vacuum a tuple, it has to satisfy the
necessary snapshot requirements. i will never be able to reduce the chain to
just one, because the there is always a indirection at the top of HOT. I
understood this.
My question was is it the
On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
> For some time I have been working on removing some inefficiencies
> from a large DW-type app. This app does a large daily batch update,
> and this is what is the major bottleneck. One of the things I have
> been doing is to remove
On 11/2/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 02, 2007 at 06:12:37PM +0530, Gokulakannan Somasundaram wrote:
> > I am especially interested in the case of continuing the HOT chain
> across
> > pages. When we are actually reclaiming space, we should check the
> snapsh
For some time I have been working on removing some inefficiencies from a
large DW-type app. This app does a large daily batch update, and this is
what is the major bottleneck. One of the things I have been doing is to
remove unnecessary updates (which are particualrly expensive in our
index-r
Jeff Trout <[EMAIL PROTECTED]> writes:
> I'm migrating from some opterons to some xeons (E5345) both are
> running x86_64. At first I figured I'd need to dump & load my data,
> which will be painful. But on a whim I made a test db on the
> opteron, copied it over (tar) and it fired up and wo
On Fri, Nov 02, 2007 at 06:12:37PM +0530, Gokulakannan Somasundaram wrote:
> I am especially interested in the case of continuing the HOT chain across
> pages. When we are actually reclaiming space, we should check the snapshot
> and reclaim it. If it is HOT updated, we will leave the top most tupl
Hey folks,
Asking here since it may deal with clever things such as alignment
and or binary reps.
I'm migrating from some opterons to some xeons (E5345) both are
running x86_64. At first I figured I'd need to dump & load my data,
which will be painful. But on a whim I made a test db on t
I went through the README on HOT. That was really a nice and cool feature.
Hats off to the person who thought about it. I have a couple of doubts about
it.
a) In the README, there is a statement like this.
In principle we could continue a HOT chain across
pages, but this would destroy the desired
I think Simon Riggs is already working on that idea. This one is
fairly easy to implement. I think these are some of the features
only a time-stamp based database can implement. I think database
standards were formed during the time, when the data consistency
was provided with Lock based
--On Freitag, November 02, 2007 10:54:45 + Gregory Stark
<[EMAIL PROTECTED]> wrote:
I think this module should be rewritten to depend more closely on the
Postgres source files. What I'm doing now is making an SRF in the style
of the pageinspect module which will read an arbitrary wal file a
On 11/2/07, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
>
> On 11/2/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
> > If the proposal is implemented
> > BEGIN
> >
> > savepoint s1;
> >
> > some DML operations
> >
> > get current inventory2 = select ...
> >
> > if current inventory2 is < f
On 11/2/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
> If the proposal is implemented
> BEGIN
>
> savepoint s1;
>
> some DML operations
>
> get current inventory2 = select ...
>
> if current inventory2 is < fixed size
> current inventory1 = select .. as of savepoint s1;
> END
>
> Do
Heikki Linnakangas wrote:
> Gregory Stark wrote:
>> There's an xlogdump project on pgfoundry. However it suffers from
>> perennial
>> bitrot as it has to maintain its own table of xlog record types and
>> code to
>> decode each xlog record type.
>>
>> ...
>>
>> I think this module should be rewritt
Gregory Stark wrote:
There's an xlogdump project on pgfoundry. However it suffers from perennial
bitrot as it has to maintain its own table of xlog record types and code to
decode each xlog record type.
...
I think this module should be rewritten to depend more closely on the Postgres
source fi
There's an xlogdump project on pgfoundry. However it suffers from perennial
bitrot as it has to maintain its own table of xlog record types and code to
decode each xlog record type.
Earlier I modified xlogdump to generate a CSV loadable data set so I could do
some basic analysis and see what type
On 11/2/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 02, 2007 at 02:43:44PM +0530, Gokulakannan Somasundaram wrote:
> > Hi,
> >I would like to propose an additional feature for Postgres to enable
> > time-travelling inside a transaction.
>
>
>
> > This would reduce the
The documentation doesn't really tell how to disable synchronous
commits for a single commit. I believe the correct command is
SET LOCAL synchronous_commit TO OFF;
just before the COMMIT statement.
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH http://www.
On Fri, Nov 02, 2007 at 02:43:44PM +0530, Gokulakannan Somasundaram wrote:
> Hi,
>I would like to propose an additional feature for Postgres to enable
> time-travelling inside a transaction.
> This would reduce the requirement for Serializable transactions in some
> cases and adds one more f
Hi,
I would like to propose an additional feature for Postgres to enable
time-travelling inside a transaction.
I went through the source code and i found Savepoint is already saving the
necessary information. But currently it doesn't store the CommandId.
This change, if implemented would save
57 matches
Mail list logo
