I have applied the E'' escape patch to CVS head.
I am attaching a smaller version that doesn't have the
escape_string_warning GUC and none of the adjustments to our code to use
E''.
I am thinking I should apply this to 8.0.X and 7.4.X? OK? Earlier
versions?
--
Bruce Momjian
> If the StringInfo API were extended to use lengths...
Er, like appendBinaryStringInfo() perhaps? ;-)
Looks like what we need is there, it only lacks the offset adjustment of our
bytebuffer.
We should redo the copy.c with appendBinaryStringInfo() I think.
- Luke
---
Alon,
> Hmm, now that I look back at them I can't remember why I thought it is
> slower. Certainly using appendStringInfoCharMacro for every char is very
> slow, but I could probably use appendStringInfoString and it should be as
> fast as using the bytebuffer, they both do a straight forward mem
Hmm, now that I look back at them I can't remember why I thought it is
slower. Certainly using appendStringInfoCharMacro for every char is very
slow, but I could probably use appendStringInfoString and it should be as
fast as using the bytebuffer, they both do a straight forward memcpy.
Alon.
On
One more thing, do you have more concerns about that max connection out
of the fact it uses pgstat ?
For example are guc variables ok for this or should it be new variable
in pg_shadow & pg_database etc - I would like to rewrite it just once or
twice not ten times.
--
Regards
Petr Jelinek (PJM
Tom Lane napsal(a):
[ shrug... ] Don't see that here; sure it isn't something broken in
your local modified version?
Well I tryed it with unmodified cvs copy and I have numbackends is 0
when 40 clients are connected (using default config)
I am bit confused now because I am no really sure
=?windows-1250?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What bug exactly?
>>
> Database stats aren't initialized so everything in pg_stat_database is
> always zero.
[ shrug... ] Don't see that here; sure it isn't something broken in
your local modified version?
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> A struct "bytebuffer" is used instead of a StringInfoData for storing the
> line and attributes. A StringInfoData is actually really cool and useful,
> but we don't really need it's formatting capabilities in COPY FROM (as far
> as I know), and so the b
Tom Lane wrote:
What bug exactly?
Database stats aren't initialized so everything in pg_stat_database is
always zero.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> What about this one:
> case COPY_OLD_FE:
> +ereport(ERROR,
> + (errcode(ERRCODE_CONNECTION_FAILURE),
> + errmsg("Old FE protocal not yet supported in fast COPY processing
> (CopyGetData())")));
> This can't stay like it is, can it
=?windows-1250?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> BTW you should still apply that pgstat.c.diff because it fixes bug in
> current CVS
What bug exactly?
regards, tom lane
---(end of broadcast)---
TIP 9: In vers
Just remembered another thing.
A struct "bytebuffer" is used instead of a StringInfoData for storing the
line and attributes. A StringInfoData is actually really cool and useful,
but we don't really need it's formatting capabilities in COPY FROM (as far
as I know), and so the bytebuffer is more st
Alon,
> If I remember more relevant things I'll post them here.
>
> Hope that helps, please ask more if there are unclear things!
Good detail, very useful!
- Luke
---(end of broadcast)---
TIP 7: don't forget to increase your free space map sett
> I haven't seen any demand for users to be allowed to specify an escape char
> in text mode (BTW, that's what the docs call what you have called delimited
> mode). Maybe there's a case for it, but I somewhat doubt it.
I ran into users that could not load their data using COPY because their
data
Andrew,
> What I would like to have is a high level description of
> . how the new text mode code differs from the old text mode code, and
> . which part of the change is responsible for how much performance gain.
>
> Maybe I have missed that in previous discussion, but this change is
> sufficien
> What about this one:
> case COPY_OLD_FE:
> +ereport(ERROR,
> + (errcode(ERRCODE_CONNECTION_FAILURE),
> + errmsg("Old FE protocal not yet supported in fast COPY processing
> (CopyGetData())")));
> +
>
> This can't stay like it is, can it?
> Who uses the old FE protocol for CO
Andrew Dunstan wrote:
Is this what is intended by the TODO item? I thought that it was intended to
allow max connections to be specified on a per-db or per-user basis, not
just for global limits on per-user or per-db connections.
They are - ALTER DATABASE dbname SET max_db_conenctions = '10'
Luke Lonergan wrote:
I've attached Alon's patch ported to the CVS trunk. It applies cleanly
and
passes the regressions. With fsync=false it is 40% faster loading a
sample
dataset with 15 columns of varied type. It's 19% faster with fsync=true.
This patch separates the CopyFrom code into two
Petr Jelínek said:
>
> Something about patch:
> I added two new guc variables name max_db_connections and
> max_user_connections which can be set by superuser which means it can
> be in main config file or in user/database config.
Is this what is intended by the TODO item? I thought that it was
Ok didn't know that stats are well behind actual state - I used pgstat
because it already stores number of conenctions per database so I
thought doing same thing again is needless.
So you think I should store those data somewhere myself. What you think
is best place, some extra hash or in system
=?ISO-8859-2?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> patch I attached allows to set connectin limits per user or per database
> (it's on TODO list).
I don't think this is going to work. The first problem with it is that
it changes pgstats from an optional into a required part of the sys
Alon Goldshuv said:
> Andrew,
>
>> 4. We should indeed do this for CSV, especially since a lot of the
>> relevant logic for detecting attribute starts is already there for CSV
>> in CopyReadLine. I'm prepared to help you do that if necessary, since
>> I'm guilty of perpetrating that code.
>
> That
Luke Lonergan said:
>> 4. We should indeed do this for CSV, especially since a lot of the
>> relevant logic for detecting attribute starts is already there for CSV
>> in CopyReadLine. I'm prepared to help you do that if necessary, since
>> I'm guilty of perpetrating that code.
>
> That would be aw
Hello,
patch I attached allows to set connectin limits per user or per database
(it's on TODO list).
It's proposal because I am not sure if this implementation can be
accepted (I never made new feature patch for postgres so I really dunno)
and I would like to know what you guys think about it
Martin Pitt wrote:
> Hi!
>
> Peter Eisentraut [2005-06-25 11:29 +0200]:
> > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> > > We absolutely want to support multiple installed versions of PostgreSQL.
> >
> > But we don't support installing multiple versions on top of each other,
> > wh
Andrew,
Thanks for your initial feedback.
> 2. This comment raises a flag in my mind:
>
> + * each attribute begins. If a specific attribute is not used for this
> + * COPY command (ommitted from the column list), a value of 0 will be
> assigned.+ * For example: for table foo(a,b,c,d,e) and COPY
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >Do we need a TODO item?
> >
> >
>
> Sure, Maybe two:
>
> . pass arrays natively instead of as text between plperl and postgres
> . add support for polymorphic arguments and return types to plperl
Added to TODO:
o Pass arrays nat
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> >> We absolutely want to support multiple installed versions of PostgreSQL.
>
> > But we don't support installing multiple versions on top of each other,
> > which
> > is th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
>> We absolutely want to support multiple installed versions of PostgreSQL.
> But we don't support installing multiple versions on top of each other, which
> is the only scenario where this patch
Bruce Momjian wrote:
Do we need a TODO item?
Sure, Maybe two:
. pass arrays natively instead of as text between plperl and postgres
. add support for polymorphic arguments and return types to plperl
cheers
andrew
---(end of broadcast)--
Do we need a TODO item?
---
Andrew Dunstan wrote:
>
> This was the patch that I took the array processing piece from and
> attempted to fix, since it was badly broken. However, I'm not happy
> about any of the ways of doi
This was the patch that I took the array processing piece from and
attempted to fix, since it was badly broken. However, I'm not happy
about any of the ways of doing it, and suspect I won't get it done for
8.1. I think we need that piece done before we look at ANYELEMENT/ANYARRAY.
cheers
an
Luke Lonergan said:
> I've attached Alon's patch ported to the CVS trunk. It applies cleanly
> and passes the regressions. With fsync=false it is 40% faster loading
> a sample dataset with 15 columns of varied type. It's 19% faster with
> fsync=true.
>
> This patch separates the CopyFrom code in
Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> We absolutely want to support multiple installed versions of PostgreSQL.
But we don't support installing multiple versions on top of each other, which
is the only scenario where this patch would be useful.
---(end o
34 matches
Mail list logo
