Thanks to everyone for the feedback that I've received so far. It's
clear that there's interest in this.
On Jun 12, 2006, at 3:22 , Josh Berkus wrote:
I do think Jim is right, though, in that we may want to look for
portions of
the functionality which are achievable in the context of one
P
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This is just nonsense. There is not the slightest reason that CSV data
> cannot be embedded in a text dump nor exist as the data members of a
> custom or tar dump with the corresponding COPY statements modified
> accordingly.
Well, the really *core*
On Tue, Jun 13, 2006 at 11:13:55PM -0300, Marc G. Fournier wrote:
> >BTW, there's another FBSD performance odditiy I've run across. Running
> >
> >pg_dump -t email_contrib -COx stats | bzip2 > ec.sql.bz2 &
> >
> >which dumps the email_contrib table to bzip2 then to disk, the OS won't
> >use more t
Bruce Momjian writes:
> Right. What if the postmaster signals the backend once a second to do
> their reporting. I am not sure what the final solution will be, but we
> _need_ one based on the performance numbers I and others have seen.
> Could we have PGPROC have a reporting boolean that is se
On Tue, 13 Jun 2006, Jim Nasby wrote:
On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
FYI, the biggest source of contention is via semop() - it might be
possible to optimize that some more in FreeBSD, I don't know.
Yeah, I've seen PostgreSQL on FreeBSD fall over at high load with a lot
of
On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
FYI, the biggest source of contention is via semop() - it might be
possible to optimize that some more in FreeBSD, I don't know.
Yeah, I've seen PostgreSQL on FreeBSD fall over at high load with
a lot
of procs in either semwait or semlock.
Bruce Momjian wrote:
pg_dump CSV TODO item removed until we come up with something everyone
can agree on.
That's a pity.
Just to show you how little is involved in what I was suggesting, a
prototype patch is attached - it's 182 lines of context diff, which is
pretty small for a new fe
Martijn van Oosterhout writes:
> What I was thinking is why we couldn't just store the information in a
> global shared system table that is only read on config reload. You
> could have a few columns, maybe the first being a list name, which is
> referenced from a GUC.
Hmmm ... if we keep the not
On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote:
> On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > Any particular reason this can't be a normal table in pg_catalog which
> > > you can select/update.
> >
> > That doesn't do
On Tue, Jun 13, 2006 at 05:05:31PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Jim C. Nasby wrote:
> > >> Excellent. Did I miss discussion of that or have you not mentioned it?
> > >> I'm curious as to how you're fixing it...
> >
> > > The patches are in the hold
On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Any particular reason this can't be a normal table in pg_catalog which
> > you can select/update.
>
> That doesn't do anything to help with one of the main problems: that
> we have at least two (maybe m
pg_dump CSV TODO item removed until we come up with something everyone
can agree on.
---
Joshua D. Drake wrote:
> >
> > Would that be adequate, or do we really want to reimplement and maintain
> > all
> > the output format
Tom Lane wrote:
> Bruce Momjian writes:
> > Jim C. Nasby wrote:
> >> Excellent. Did I miss discussion of that or have you not mentioned it?
> >> I'm curious as to how you're fixing it...
>
> > The patches are in the hold queue:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Tha
> That's talking about the stats code, which has approximately
> zip to do with setproctitle (ps_status.c). But IIRC that
> patch is on hold because nobody particularly liked the
> approach it's taking. I think we should investigate
> rewriting the stats communication architecture entirely --
On Tue, Jun 13, 2006 at 04:35:24PM -0400, Tom Lane wrote:
> ... The main objection I see to this is that it replaces a kernel
> call that actually does some work with a kernel call to start a timer,
> plus possibly a later kernel call to actually do the work. Not clear
> that there's a win there.
Bruce Momjian writes:
> Jim C. Nasby wrote:
>> Excellent. Did I miss discussion of that or have you not mentioned it?
>> I'm curious as to how you're fixing it...
> The patches are in the hold queue:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
That's talking about the stats code
Hi,
I was just talking to Derick the author of DBGp and I realized this
might be a topic for a joint effort among all open source RDBMS. I think
it would be awesome if we could get a common protocol setup for stored
procedure debugging.
regards,
Lukas
---(end of broa
Jim C. Nasby wrote:
> On Tue, Jun 13, 2006 at 02:10:15PM -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > FWIW, getting turning off stats_command_string substantially reduced
> > > this contention, so it appears the issue is somewhere in the stats code.
> > > This code sends stats messages
On Tue, Jun 13, 2006 at 02:10:15PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > FWIW, getting turning off stats_command_string substantially reduced
> > this contention, so it appears the issue is somewhere in the stats code.
> > This code sends stats messages to a different process via a
Jim C. Nasby wrote:
> FWIW, getting turning off stats_command_string substantially reduced
> this contention, so it appears the issue is somewhere in the stats code.
> This code sends stats messages to a different process via a socket (or
> is it UDP?), with the intention that if the system gets he
On Tue, 2006-06-13 at 15:00 +0200, Martijn van Oosterhout wrote:
> What you might be able to do is to reduce its effect. The thing that
> occurs to me is to make hint bit changes only mark a page half-dirty.
> If the page is evicted because the space is needed in the buffer cache,
> it can be just
On Mon, Jun 12, 2006 at 11:38:01AM -0400, Kris Kennaway wrote:
> On Mon, Jun 12, 2006 at 10:08:22AM -0500, Jim C. Nasby wrote:
> > On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> > > On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > > > On Sun, Jun 11, 2006 at 09:58
Steve Atkins wrote:
Would that be adequate, or do we really want to reimplement and
maintain all
the output format complexity in our own code, in C?
Code to produce CSVs is there, now, today, and has been since 8.0. That
is *not* what is at issue here. If you want to debate whether o
On Jun 13, 2006, at 9:47 AM, Joshua D. Drake wrote:
Would that be adequate, or do we really want to reimplement and
maintain all
the output format complexity in our own code, in C?
I think the point is that we should provide a native implementation
because not everyone is crazy enough to
> From: Rod Taylor [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 13, 2006 11:31 AM
>
>
> On Mon, 2006-06-12 at 16:28 -0400, Bill Bartlett wrote:
> > Can't -- the main production database is over at a CoLo site with
> > access only available via SSH, and tightly-restricted SSH at that.
> > Ge
Would that be adequate, or do we really want to reimplement and maintain
all
the output format complexity in our own code, in C?
I think the point is that we should provide a native implementation
because not everyone is crazy enough to use perl (blatant jab ;)). I
would never expect a cust
PFC wrote:
From what I gather, the CSV format dump would only contain data.
I think pg_dump is the friend of pg_restore. It dumps everything
including user defined functions, types, schemas etc. CSV does not
fit with this.
This is just nonsense. There is not the slightest
From what I gather, the CSV format dump would only contain data.
I think pg_dump is the friend of pg_restore. It dumps everything
including user defined functions, types, schemas etc. CSV does not fit
with this.
Besides, people will probably want to dump into CSV the result of any
Rod Taylor wrote:
On Mon, 2006-06-12 at 16:28 -0400, Bill Bartlett wrote:
Can't -- the main production database is over at a CoLo site with access
only available via SSH, and tightly-restricted SSH at that. Generally
one of the developers will SSH over to the server, pull out whatever
data is ne
On Jun 13, 2006, at 7:34 AM, Martijn van Oosterhout wrote:
What this tells me is that we need a tool somewhere between psql and
pg_dump, say, pgquery. It's sole purpose in life is to generate output
from various queries. Because it's a seperate tool there's no question
of psql or pg_dump being
Martijn van Oosterhout writes:
> Any particular reason this can't be a normal table in pg_catalog which
> you can select/update.
That doesn't do anything to help with one of the main problems: that
we have at least two (maybe more) alternative sets of names that people
might want as default. Get
On Mon, 2006-06-12 at 16:28 -0400, Bill Bartlett wrote:
> Can't -- the main production database is over at a CoLo site with access
> only available via SSH, and tightly-restricted SSH at that. Generally
> one of the developers will SSH over to the server, pull out whatever
> data is needed into a t
Martijn van Oosterhout wrote:
Side note: In my experience Excel happily slurps up tab delimited
output, so I'm not sure why all of this is an issue in the first place.
I guess you experience doesn't run to data that has embedded tabs, for
example.
There really is a reason we did this
On Tue, 2006-06-13 at 10:02 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Elsewhere, it has been discussed that we might hold the number of blocks
> > in a relation in shared memory. Does that idea now fall down, or is it
> > complementary to this?
>
> It's been the case for
Volkan YAZICI wrote:
On Jun 13 10:20, Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
IMHO, it might be better if we'd support a syntax
Joachim Wieland <[EMAIL PROTECTED]> writes:
> The timezone definition files should be read at server start but should they
> also be read at SIGHUP? If so, should they be read only by the postmaster or
> by all backends?
Presumably the name of the definition file to use will be a GUC
variable. I
Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
Although I don't see a real need for the feature, I do think that if we
were to support "1" (well
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> What you are seeing is the now infamous "Postgres writes a table one more
> time after loading" behavior.
> Tom - can you explain what's going on with this?
Setting XMIN_COMMITTED hint bits.
regards, tom lane
Tom Lane wrote:
there are half a dozen more sub-options, and it seems like every time we
turn around someone is finding a reason for another one.
This is a bit unfair. The feature was introduced in 8.0, and slightly
enhanced in 8.1. There have not been any additional CSV features this
On Jun 13 10:20, Bruce Momjian wrote:
>
> Good point. The number of CSV options would be hard to support for
> pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
> just support the default behavior?
IMHO, it might be better if we'd support a syntax like
pg_dump --csv=opt0
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 13 June 2006 14:42
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_get_INDEXdef - opclass
>
> "Dave Page" writes:
> > Right, but how can I conditionally join with pg_opclass
> base
On Tue, Jun 13, 2006 at 10:20:53AM -0400, Bruce Momjian wrote:
>
> Good point. The number of CSV options would be hard to support for
> pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
> just support the default behavior?
What this tells me is that we need a tool somewhere
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
---
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PR
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I wish I could understand why people are so keen to make other people turn
> handsprings in order to avoid a feature which, as Bruce points out, is
> already on the TODO list, and which, by my 10 minute analysis, would involve
> almost trivial code imp
Simon Riggs <[EMAIL PROTECTED]> writes:
> Elsewhere, it has been discussed that we might hold the number of blocks
> in a relation in shared memory. Does that idea now fall down, or is it
> complementary to this?
It's been the case for some time that the planner uses
RelationGetNumberOfBlocks() to
"Dave Page" writes:
> Right, but how can I conditionally join with pg_opclass based on whether
> or not the opclass specified for the column is the default for that
> type?
Check pg_opclass.opcdefault and compare pg_opclass.opcintype to the
index column's datatype (which you'd get from its pg_att
Martin,
On 6/13/06 6:00 AM, "Martijn van Oosterhout" wrote:
> What you might be able to do is to reduce its effect. The thing that
> occurs to me is to make hint bit changes only mark a page half-dirty.
> If the page is evicted because the space is needed in the buffer cache,
> it can be just dr
Andrew Dunstan wrote:
> Matthew T. OConnor said:
> > Bill Bartlett wrote:
> >> Can't -- the main production database is over at a CoLo site with
> >> access only available via SSH, and tightly-restricted SSH at that.
> >> Generally one of the developers will SSH over to the server, pull out
> >> wh
Matthew T. OConnor said:
> Bill Bartlett wrote:
>> Can't -- the main production database is over at a CoLo site with
>> access only available via SSH, and tightly-restricted SSH at that.
>> Generally one of the developers will SSH over to the server, pull out
>> whatever data is needed into a text
On Tue, Jun 13, 2006 at 05:46:23AM -0700, Luke Lonergan wrote:
> Martin,
>
> On 6/13/06 5:42 AM, "Martijn van Oosterhout" wrote:
>
> > Is it possible it may have something to do with the hint bits? There's
> > are a bunch of bits in the header to deal with speeding up of MVCC
> > tests. Maybe ch
On Tue, Jun 13, 2006 at 02:20:09PM +0200, Joachim Wieland wrote:
> I looked into the timezone specifications and basically extracted a list of
> existing offsets from the zic database.
>
> My proposed format for the timezone files is something like this:
Any particular reason this can't be a no
Martin,
On 6/13/06 5:42 AM, "Martijn van Oosterhout" wrote:
> Is it possible it may have something to do with the hint bits? There's
> are a bunch of bits in the header to deal with speeding up of MVCC
> tests. Maybe changing those bits marks the page dirty and forces a
> write?
Yes, that's it.
On Tue, Jun 13, 2006 at 04:54:05AM -0700, Luke Lonergan wrote:
> > Experimental results here suggest that for larger tables Linux seems
> > to detect a seq-scan and not bother caching. It's very reproducible
> > for me here to do a reboot and not see the full speedup on a seq_scan
> > until the t
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
HADT -32400 D # Hawaii-Aleutain Daylight Time
# (America/Adak)
HAST -36000# Hawaii-Al
Bill Bartlett wrote:
Can't -- the main production database is over at a CoLo site with access
only available via SSH, and tightly-restricted SSH at that. Generally
one of the developers will SSH over to the server, pull out whatever
data is needed into a text file via psql or pg_dump, scp the fil
Ron,
On 6/8/06 11:49 AM, "Ron Mayer" <[EMAIL PROTECTED]> wrote:
> Experimental results here suggest that for larger tables Linux seems
> to detect a seq-scan and not bother caching. It's very reproducible
> for me here to do a reboot and not see the full speedup on a seq_scan
> until the third
On Mon, Jun 12, 2006 at 10:08:22AM -0500, Jim C. Nasby wrote:
> On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> > On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > > On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > > > Kris Kennaway <[EMAIL PROTECTED]>
On Mon, Jun 12, 2006 at 08:14:01PM -0400, Tom Lane wrote:
> I had interpreted the readline documentation to mean that readline would
> discard a partially typed line upon catching SIGINT. Experimentation
> shows that this is not so, at least not with the version of readline I
> use here. It does
On Mon, 2006-06-12 at 19:15 -0400, Tom Lane wrote:
> [ moving to -hackers to get some more eyeballs on the question ]
>
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sun, 2006-06-11 at 17:53 -0400, Alvaro Herrera wrote:
> >> Here I repost the patch to implement non-transactional catalogs, the
>
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 12 June 2006 18:32
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_get_INDEXdef - opclass
>
> "Dave Page" writes:
> >> Following a pgAdmin bug report, I noticed that
> pg_get_viewd
60 matches
Mail list logo
