Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... This was in response to your request
> So obviously, there are a few possible solutions. We just have to
> pick one we like best.
Check.
> We could actually query make whether it supports order-only prerequisites and
> only use the developer-op
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> ...
> Neither the "dealer", nor the "workers" would need access to the either
> the shared memory or the disk, thereby not messing with the "one backend
> is one transaction is one session" dogma.
> ...
Unfortunately, this idea has far too narrow a
On Wed, Feb 27, 2008 at 2:29 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > You could just pull up a psql session and do a "select
> > pg_func_def(regproc);" and there you go, one fully formed CREATE
> > FUNCTION statement.
>
> \df+ function(type)
>
Sure, if your idea of a good time is lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 27 Feb 2008 13:05:44 +1100
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
>
> You could just pull up a psql session and do a "select
> pg_func_def(regproc);" and there you go, one fully formed CREATE
> FUNCTION statement.
\df+ function(type)
Jo
As far as I can see the main difficulty in making COPY run faster (on
the server) is that pretty involved conversion from plain-text lines
into tuples. Trying to get rid of this conversion by having the client
send something that resembles the data stored in on-disk tuples is not a
good answer, ei
Tom Lane wrote:
The concern I've got about this is basically that it would encourage
plastering the same label on subtly different counts, leading to
confusion and perhaps mistaken conclusions. I would prefer to see any
common probes be reverse-engineered *after the fact*, ie, after you've
alrea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, February 26, 2008 14:57:33 -0800 "Joshua D. Drake"
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 26 Feb 2008 14:47:09 -0800
> Josh Berkus <[EMAIL PROTECTED]> wrote:
>
>> Robert,
>>
>> > Int
On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> I haven't found any option to dump any user-defined function stored in a
> database, unless doing a pg_dump -D -s database, but so far one would get the
> definitions of the tables, the permissions, the triggers, and s
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I think a sane way to think about what Simon would like to accomplish
> is not "turn psql into a parallel job scheduler" but "teach pg_restore
> how to do parallel scheduling, and then see if it can be made to do
> anything useful with plain-text instead of
On 27/02/2008, Neil Conway <[EMAIL PROTECTED]> wrote:
> I think you need human verification / analysis, which isn't an easy
> thing to script.
Is that site publicly accessible, do they have some sample
output that one could examine in regards to Joshua's parsing
idea?
> -Neil
Cheers,
Andrej
--
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > only objfiles.txt uses the somewhat arcane feature that is apparently
> > breaking dawn_bat - it is apparently not used anywhere else in our build
> > system.
> >
> > Is that really the only way we can do it? Maybe Peter understands i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 19:03:57 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> So you have four serialization points not just one; at each one the
> slowest subtask forces everyone else to wait, even if there's work
> that could potentially be done on other
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> How exactly are you allocating tasks to threads in this prototype,
>> anyway?
> Right there is no balance here. Let me explain what I did. I performed
> a pg_restore -l to get the TOC file. I then broke that fil
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> only objfiles.txt uses the somewhat arcane feature that is apparently
> breaking dawn_bat - it is apparently not used anywhere else in our build
> system.
> Is that really the only way we can do it? Maybe Peter understands it but
> I don't, and I'm n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 18:39:53 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > However one observation that I am going to (try) to test is that we
> > are spending a lot of time waiting for the last thread t
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
There is a build farm failure now because (apparently) an old make version:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-02-26%2019:00:01
The new amended backend linking code needs GNU make 3.8
On Tue, 2008-02-26 at 14:57 -0800, Joshua D. Drake wrote:
> Would there be a way to script the responses to flag us for things
> that are important?
I think you need human verification / analysis, which isn't an easy
thing to script.
-Neil
---(end of broadcast)
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> However one observation that I am going to (try) to test is that we are
> spending a lot of time waiting for the last thread to finish.
IOW you haven't balanced the work given to each thread very well?
Or is there something else happening?
How exact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 07:43:23 -0800
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008 22:25:09 -0800
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> 24 connections: 3.5 hours
> 12 connections: 4.5 hours
>
24 connections RAW_BUF_S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 14:47:09 -0800
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Robert,
>
> > Interesting, seems pghackers dropped me from the list, so I missed
> > several messages in the thread.
>
> Huh. I thougth this was just my full mailbox ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 14:45:23 -0800
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Neil,
>
> > I take a look at this periodically. Apparently the last run of the
> > tool for Postgres happened on October 30th -- do you know if
> > there's a way to schedule
Robert,
> Interesting, seems pghackers dropped me from the list, so I missed
> several messages in the thread.
Huh. I thougth this was just my full mailbox ... I missed all of the
messages this weekend. Who else got nailed?
Marc?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
Neil,
> I take a look at this periodically. Apparently the last run of the tool
> for Postgres happened on October 30th -- do you know if there's a way to
> schedule more frequent runs?
If we get volunteers set up, they will start running it daily.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Fr
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> We can easily, and backwards-compatibly, improve pg_restore to do
>> concurrent restores. Trying to make psql do something like this will
>> require a complete rewrite, and there is no prospect that it will work
Robert Lor <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm unimpressed; it's not at all clear that you'd be measuring quite the
>> same thing in, say, mysql as in postgres.
> I think it depends on the probe, but for transaction rates like start or
> commit, don't you think it's pretty black
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There is a build farm failure now because (apparently) an old make version:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-02-26%2019:00:01
> The new amended backend linking code needs GNU make 3.80, released
> 2002-10-03.
Gregory Stark wrote:
I think both types of probes are useful to different people.
I think certain higher level probes can be really useful to DBAs.
Perhaps looking at the standard database SNMP MIB counters would give us a
place to start for upward facing events people want to trace for data
There is a build farm failure now because (apparently) an old make version:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-02-26%2019:00:01
The new amended backend linking code needs GNU make 3.80, released 2002-10-03.
Should we just require that? I think the PARTIAL_L
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> I've not been advocating improving pg_restore, which is where the -Fc
>> tricks come in.
>> ...
>> I see you thought I meant pg_restore. I don't thinking extending
>> pg_restore in that way is of sufficiently gener
On Tuesday 26 February 2008 12:20, Andrew Dunstan wrote:
> Robert Treat wrote:
> > There are a lot of people who have a database provider of some sort who
> > creates a database for them, giving them ownership of that specific
> > database, with pg_hba.conf specifying connection only to that db. Th
On Tue, 2008-02-26 at 11:33 -0800, Josh Berkus wrote:
> We need two (or more) PostgreSQL hackers to volunteer to regularly check the
> Coverity reports and either fix/forward the bugs found, or (more often) mark
> them as non-bugs in the Coverity system.
I take a look at this periodically. Appar
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Possibly I have a different view of the uses of dtrace than you do, but
> most of the events I'd be interested in probing are probably pretty
> Postgres-specific.
I think both types of probes are useful to different people.
One of the really neat things
Hackers,
As you may have read, Coverity is running their static analysis tool ("Scan")
against the PostgreSQL codebase daily: http://scan.coverity.com/
We need two (or more) PostgreSQL hackers to volunteer to regularly check the
Coverity reports and either fix/forward the bugs found, or (more o
On Tue, 2008-02-26 at 14:55 -0500, Tom Lane wrote:
> Anyway I think they both have their place.
I think it is very fragile to have the semantics of a builtin datatype
change depending on a configure option. It makes it difficult to write
applications that depend on the unique properties of *either
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> HOT works because EDB refused to accept the inherit limitations of
> PostgreSQL. COPY is no different in that aspect. Maybe it can't go
> exponentially faster but the math says, "if done correctly, it can".
You can always make it faster if it doesn't
Tom,
> That argument *was* valid ... before 8.3. Nowadays non-superuser DB
> owners can install trusted PLs in their DBs by themselves. (At least
> by default.) So I'm still unconvinced that we need more changes.
I agree.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
>> As a result, I have a few questions about the timestamp code. In what
>> instances is the floating point timestamp recommended?
> One circumstance is when there isn't a native int64 type available.
On Tue, 2008-02-26 at 13:18 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've not been advocating improving pg_restore, which is where the -Fc
> > tricks come in.
> > ...
> > I see you thought I meant pg_restore. I don't thinking extending
> > pg_restore in that way is of su
On Tue, 2008-02-26 at 16:18 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > IMO the place to start is COPY which is per my tests, slow. Multi
> > > worker connection restore is great and I have proven that with some
> > > work it can provide o.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 14:17:24 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Feb 2008, Tom Lane wrote:
>
> > What are you imagining here ... a plain SQL script containing
> > database-independent INSERT commands? That's going to suck
Tom Lane wrote:
I'm unimpressed; it's not at all clear that you'd be measuring quite the
same thing in, say, mysql as in postgres.
I think it depends on the probe, but for transaction rates like start or
commit, don't you think it's pretty black & white as long as the probes
are placed in th
On Tue, 2008-02-26 at 13:18 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've not been advocating improving pg_restore, which is where the -Fc
> > tricks come in.
> > ...
> > I see you thought I meant pg_restore. I don't thinking extending
> > pg_restore in that way is of su
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > IMO the place to start is COPY which is per my tests, slow. Multi
> > worker connection restore is great and I have proven that with some
> > work it can provide o.k. results but it is certainly not acceptable.
>
> It was already
On Tue, 26 Feb 2008, Tom Lane wrote:
What are you imagining here ... a plain SQL script containing
database-independent INSERT commands? That's going to suck compared
to COPY no matter what.
Think 100GB+ of data that's in a CSV or delimited file. Right now the
best import path is with COPY,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 13:58:25 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > IMO the place to start is COPY which is per my tests, slow. Multi
> > worker connection restore is great and I have proven that
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> IMO the place to start is COPY which is per my tests, slow. Multi
> worker connection restore is great and I have proven that with some
> work it can provide o.k. results but it is certainly not acceptable.
It was already pointed out to you that we c
Robert Lor <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm unconvinced that there will be any probes that are common to all
>> databases. I'd skip this part...
>>
> Any reason why we can't consider probes like transaction-start,
> transaction-commit, or transaction-abort as common probes th
On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
> As a result, I have a few questions about the timestamp code. In what
> instances is the floating point timestamp recommended?
One circumstance is when there isn't a native int64 type available. The
floating point datetime code is the tradi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 10:32:59 -0800
Jeff Davis <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-26 at 17:16 +, Simon Riggs wrote:
> > I've not been advocating improving pg_restore, which is where the
> > -Fc tricks come in.
>
> Oh, then it was a misco
Tom Lane wrote:
I'm unconvinced that there will be any probes that are common to all
databases. I'd skip this part...
Any reason why we can't consider probes like transaction-start,
transaction-commit, or transaction-abort as common probes that can also
be used in other (maybe no all) data
On Tue, 2008-02-26 at 17:16 +, Simon Riggs wrote:
> I've not been advocating improving pg_restore, which is where the -Fc
> tricks come in.
Oh, then it was a miscommunication on my part, because I was talking
about pg_restore, and I assumed you were as well.
Regards,
Jeff Davis
Tom Lane wrote:
Since the performance advantages are still somewhat hypothetical,
I think we should reach for the low-hanging fruit first. If concurrent
pg_restore really does prove to be the best thing since sliced bread,
*then* would be the time to start thinking about whether it's possible
Simon Riggs <[EMAIL PROTECTED]> writes:
> I've not been advocating improving pg_restore, which is where the -Fc
> tricks come in.
> ...
> I see you thought I meant pg_restore. I don't thinking extending
> pg_restore in that way is of sufficiently generic use to make it
> worthwhile. Extending psql
On Tue, 2008-02-26 at 12:27 -0500, Greg Smith wrote:
> On Tue, 26 Feb 2008, Simon Riggs wrote:
>
> > Splitting up the dump is the enabler for splitting up the load.
>
> While the pg_dump split train seems to be leaving the station, I feel
> compelled to point out that focus does nothing to help
Greg Smith <[EMAIL PROTECTED]> writes:
> While the pg_dump split train seems to be leaving the station, I feel
> compelled to point out that focus does nothing to help people who are
> bulk-loading data that came from somewhere else.
What are you imagining here ... a plain SQL script containing
Sooner or later we ought to completely reimplement LISTEN/NOTIFY,
but while thinking about Joel Stevenson's performance issue I had a
sudden idea for a very simple change that would buy some improvement.
Currently, all operations in async.c take ExclusiveLock on pg_listener,
but it strikes me that
Am Dienstag, 26. Februar 2008 schrieb Andrew Dunstan:
> This appears to have broken Win32 Mingw builds - see
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-02-26%20
>07:00:01
There have been a few changes after that. Let's see what is says in a few
hours.
--
Peter Eisentr
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thursday 21 February 2008 21:33, Tom Lane wrote:
>> So it's still 100% unclear to me who we are catering to.
> There are a lot of people who have a database provider of some sort who
> creates a database for them, giving them ownership of that specifi
On Tue, 26 Feb 2008, Simon Riggs wrote:
Splitting up the dump is the enabler for splitting up the load.
While the pg_dump split train seems to be leaving the station, I feel
compelled to point out that focus does nothing to help people who are
bulk-loading data that came from somewhere else.
On Tue, 2008-02-26 at 11:59 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So if I understand:
>
> > * we add switches to pg_dump to dump out separate files with --pre,
> > --post and --data (or other names) [TODO: Simon]
>
> > * we add switches to pg_restore to load/dump fr
Robert Treat wrote:
There are a lot of people who have a database provider of some sort who
creates a database for them, giving them ownership of that specific database,
with pg_hba.conf specifying connection only to that db. They are then free to
muck about that database, installing anything
Hi,
I'm working on a GiST opclass to support prefix searching as presented here:
http://pgsql.tapoueh.org/site/html/prefix/index.html
http://prefix.projects.postgresql.org/README.html
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/prefix/prefix/
In order to have a much more efficient index, I
On Tue, 2008-02-26 at 10:48 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > My thinking is to do either:
> > * keep it as simple as possible to allow DBA to manually improve
> > performance
> > * express dependency information in the pg_dump output to allow some
> > level of pa
Robert Treat wrote:
> They are then free to muck about that database, installing anything
> they want, but they cannot load any procedural languages since they
> only have non-superuser accounts.
Except that they can in 8.3.
--
Alvaro Herrerahttp://www.CommandPro
On Thursday 21 February 2008 21:33, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > On Thursday 21 February 2008 11:36, Tom Lane wrote:
> >> Would it satisfy people if plpgsql were in postgres, but neither
> >> template DB, after initdb?
> >
> > No, the real-world use-case we're tryin
Simon Riggs <[EMAIL PROTECTED]> writes:
> So if I understand:
> * we add switches to pg_dump to dump out separate files with --pre,
> --post and --data (or other names) [TODO: Simon]
> * we add switches to pg_restore to load/dump from the single archive
> file the subsets of --pre, --post, --data
Robert Lor <[EMAIL PROTECTED]> writes:
>> * This is unrelated to making DTrace work on Leopard, but I'd like to
>> propose that we split the probes into generic database and Postgres
>> specific providers, called "database" and "postgresql" respectively.
>> Other databases will be adding DTrace
Simon Riggs <[EMAIL PROTECTED]> writes:
> My thinking is to do either:
> * keep it as simple as possible to allow DBA to manually improve
> performance
> * express dependency information in the pg_dump output to allow some
> level of parallelism to use that information to advantage automatically
I
On Tue, 2008-02-26 at 16:28 +0100, Magnus Hagander wrote:
> On Tue, Feb 26, 2008 at 03:15:59PM +, Simon Riggs wrote:
> > So if I understand:
> >
> > * we add switches to pg_dump to dump out separate files with --pre,
> > --post and --data (or other names) [TODO: Simon]
> >
> > * we add switc
On Mon, 25 Feb 2008 22:25:09 -0800
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
24 connections: 3.5 hours
12 connections: 4.5 hours
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQ
Robert Lor wrote:
Proposed changes:
* Switch from using DTRACE_PROBEn macros to the dynamically generated
macros (remove pg_trace.h)
* Use "dtrace -h" to create a header file that contains the
dynamically generated macros to be used in the source code instead of
the DTRACE_PROBEn macros.
* Cre
On Tue, 2008-02-26 at 15:25 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > 1.41 7.25 0.13 1029CacheInvalidateHeapTuple
> >
> > which together account for more than 50% of CPU.
>
> The second column is cumulative percentage (the third column is "se
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Dienstag, 26. Februar 2008 schrieb Tom Lane:
Why should it complain more or less than about the SUBSYS.o
files?
It has a hard-wired rule not to complain about files named *.o.
Well, we could name th
On Tue, Feb 26, 2008 at 03:15:59PM +, Simon Riggs wrote:
> On Tue, 2008-02-26 at 10:03 -0500, Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > On Tue, Feb 26, 2008 at 12:39:29AM -0500, Tom Lane wrote:
> > >> BTW, what exactly was the use-case for this?
> >
> > > One use-ca
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> 1.41 7.25 0.13 1029CacheInvalidateHeapTuple
>
> which together account for more than 50% of CPU.
The second column is cumulative percentage (the third column is "self" time).
So together this function and all the items above it accoun
Le mardi 26 février 2008, Tom Lane a écrit :
>
> In short, what I think we need here is just some more conveniently
> defined extraction filter switches than --schema-only and --data-only.
> There's no need for any fundamental change to pg_dump's architecture.
Forgive me if what I will say bellow
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Tue, Feb 26, 2008 at 12:39:29AM -0500, Tom Lane wrote:
BTW, what exactly was the use-case for this?
One use-case would be when you have to make some small change to the schema
while reloading it, that's still
On Tue, 2008-02-26 at 10:03 -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Tue, Feb 26, 2008 at 12:39:29AM -0500, Tom Lane wrote:
> >> BTW, what exactly was the use-case for this?
>
> > One use-case would be when you have to make some small change to the schema
> > whi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 26. Februar 2008 schrieb Tom Lane:
>>> Why should it complain more or less than about the SUBSYS.o
>>> files?
>>
>> It has a hard-wired rule not to complain about files named *.o.
> Well, we could name the output file SUBSYS.o if that is
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.
I'd be very pleased to give you more details.
Thenks for your time.
Regards, Manolo.
-
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Feb 26, 2008 at 12:39:29AM -0500, Tom Lane wrote:
>> BTW, what exactly was the use-case for this?
> One use-case would be when you have to make some small change to the schema
> while reloading it, that's still compatible with the data format.
Looking at the profile for COPY and then a profile for CREATE TABLE AS
SELECT (CTAS) there is clearly too much overhead caused by inserting the
rows one at a time.
Flat profile of CTAS: (2 cols of this output removed for clarity)
Each sample counts as 0.01 seconds.
% cumulative self
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 26, 2008 8:17 AM
> To: Roberts, Jon
> Cc: Andrew Dunstan; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pgAgent job limit
>
> On Tue, Feb 26, 2008 at 08:10:09AM -0600, Roberts, Jon wro
Magnus Hagander wrote:
On Tue, Feb 26, 2008 at 08:28:11AM -0500, Andrew Dunstan wrote:
Simon Riggs wrote:
Separate files seems much simpler...
Yes, We need to stick to the KISS principle.
ISTM that we could simply invent a new archive format of "d" for directory.
Yeah, you can always ZIP (or
On Tue, 2008-02-26 at 15:12 +0100, Magnus Hagander wrote:
> On Tue, Feb 26, 2008 at 08:28:11AM -0500, Andrew Dunstan wrote:
> >
> >
> > Simon Riggs wrote:
> > >Separate files seems much simpler...
> > >
> > >
> >
> > Yes, We need to stick to the KISS principle.
> >
> > ISTM that we could simp
On Tue, Feb 26, 2008 at 08:10:09AM -0600, Roberts, Jon wrote:
> > Roberts, Jon wrote:
> > > In pgAgent.cpp, I would like to add LIMIT as shown below:
> > >
> > >
> > >
> >
> > [snip]
> >
> > > What do you guys think?
> > >
> > >
> > >
> >
> > What has this to do with -hackers?
> >
> > I don't e
Roberts, Jon wrote:
> > Roberts, Jon wrote:
> > > In pgAgent.cpp, I would like to add LIMIT as shown below:
> > > What do you guys think?
> >
> > What has this to do with -hackers?
> >
> > I don't even know what project this refers to - it certainly doesn't
> > refer to core postgres, which is w
On Tue, 2008-02-26 at 08:28 -0500, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > Separate files seems much simpler...
> >
> >
>
> Yes, We need to stick to the KISS principle.
>
> ISTM that we could simply invent a new archive format of "d" for directory.
...and then dump each table to a s
> Roberts, Jon wrote:
> > In pgAgent.cpp, I would like to add LIMIT as shown below:
> >
> >
> >
>
> [snip]
>
> > What do you guys think?
> >
> >
> >
>
> What has this to do with -hackers?
>
> I don't even know what project this refers to - it certainly doesn't
> refer to core postgres, which is
On Tue, Feb 26, 2008 at 08:28:11AM -0500, Andrew Dunstan wrote:
>
>
> Simon Riggs wrote:
> >Separate files seems much simpler...
> >
> >
>
> Yes, We need to stick to the KISS principle.
>
> ISTM that we could simply invent a new archive format of "d" for directory.
Yeah, you can always ZIP (
Roberts, Jon wrote:
In pgAgent.cpp, I would like to add LIMIT as shown below:
[snip]
What do you guys think?
What has this to do with -hackers?
I don't even know what project this refers to - it certainly doesn't
refer to core postgres, which is what -hackers is about.
cheer
In pgAgent.cpp, I would like to add LIMIT as shown below:
LogMessage(_("Checking for jobs to run"), LOG_DEBUG);
DBresult *res=serviceConn->Execute(
wxT("SELECT J.jobid ")
wxT(" FROM pgagent.pga_job J ")
wxT(" WHERE jobenabled ")
wxT(" AND jobagentid IS NULL ")
wxT(" AND jobnextrun <= now
Le mardi 26 février 2008, Tom Dunstan a écrit :
> On Tue, Feb 26, 2008 at 5:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Le mardi 26 février 2008, Dimitri Fontaine a écrit :
> >> We could even support some option for the user to tell us which
> >> disk arrays to use for parallel dumping.
> >>
kenneth d'souza wrote:
> Refering to this request http://momjian.us/mhonarc/patches_hold/msg00022.html
> I have created a patch. The output doesn't exaclty match with what is stated
> here
> http://momjian.us/mhonarc/patches_hold/msg00023.html. However, it
> does tell the required details in a
Simon Riggs wrote:
Separate files seems much simpler...
Yes, We need to stick to the KISS principle.
ISTM that we could simply invent a new archive format of "d" for directory.
BTW, parallel dumping might be important, but is really much less so
than parallel restoring in my book.
ch
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.
I'd be very pleased to give you more details.
Thenks for your time.
Regards, Manolo.
> > As a user I'd really prefer all of this to be much more transparent,
and could
> > well imagine the -Fc format to be some kind of TOC + zip of table
data + post
> > load instructions (organized per table), or something like this.
> > In fact just what you described, all embedded in a single
On Tue, 2008-02-26 at 18:19 +0530, Tom Dunstan wrote:
> On Tue, Feb 26, 2008 at 5:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-02-26 at 12:46 +0100, Dimitri Fontaine wrote:
> > > As a user I'd really prefer all of this to be much more transparent, and
> > could
> > > well imagi
On Tue, Feb 26, 2008 at 5:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-26 at 12:46 +0100, Dimitri Fontaine wrote:
> > As a user I'd really prefer all of this to be much more transparent, and
> could
> > well imagine the -Fc format to be some kind of TOC + zip of table data +
On Tue, 2008-02-26 at 12:46 +0100, Dimitri Fontaine wrote:
> Le mardi 26 février 2008, Simon Riggs a écrit :
> > So that would mean we would run an unload like this
> >
> > pg_dump --pre-schema-file=f1 --save-snapshot -snapshot-id=X
> > pg_dump -t bigtable --data-file=f2.1 --snapshot-id=X
> > pg_du
1 - 100 of 111 matches
Mail list logo
