Hi.
I apologize for this late reply.
Tom Lane wrote:
> I think it's probably useless. In the first place, at reasonable values
> of work_mem the effect is going to be negligible (in the sense that a
> plain indexscan would never win). In the second place, there isn't any
> way to guess the exten
Koichi Suzuki writes:
> Although xml2 was announced to be removed from 8.4, I found 8.4beta1
> documentation has xml2 description. Does it mean that xml2 is
> available in 8.4 as well?
Yes. It won't be removed until the functionality is fully covered,
and AFAIK we are quite some way from that y
HI,
Although xml2 was announced to be removed from 8.4, I found 8.4beta1
documentation has xml2 description. Does it mean that xml2 is
available in 8.4 as well?
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
This is a WIP patch (for the TODO item in the subject) that I'm putting
in the Commit Fest queue for 8.5.
regards...
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
psql_escape_client_server_version.patch.bz2
Description:
Bernd Helmle writes:
> --On Dienstag, Mai 05, 2009 10:00:37 -0400 Tom Lane
> wrote:
>> Seems like the right response might be some micro-optimization effort on
>> byteaout.
> Hmm looking into profiler statistics seems to second your suspicion:
> Normal COPY shows:
> % cumulative self
Andres Freund writes:
> As this is my first patch to PG I am happy with most sort of feedback.
Please add your patch to the commit-fest queue here:
http://wiki.postgresql.org/wiki/CommitFestInProgress
Since we are still busy with 8.4 beta, it's unlikely that anyone will
take a close look until t
"Dickson S. Guedes" writes:
> So, in a way to avoid the scenario where a ROLE has an explicit
> search_path set to schemes that already have tables named same as the
> pgbench's tables, doesn't makes sense also create a "pgbench_" suffix
> for them?
Hm, just rename the standard scenario's tables
"Joshua D. Drake" writes:
> On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
>> But, there is the possibility that someone are using an automated script
>> that could be broken by this change?
> Only if the role pgbench is using as an explicit search_path set.
Even then, it's not a p
Em Qua, 2009-05-06 às 13:49 -0700, Joshua D. Drake escreveu:
> On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
> > Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
> > > Alvaro Herrera writes:
> > > > I think it would be better that the schema is specified on the command
> > > > l
Andrew Dunstan writes:
> Tom Lane wrote:
>> Is this demonstrable, or just speculation? The incompatibilities
>> between ARE mode and (legal) ERE patterns are pretty darn small.
> It's explicitly documented. Whether or not there is a good basis for the
> documentation I can't yet say. If that's
Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
> Alvaro Herrera writes:
> > I think it would be better that the schema is specified on the command
> > line.
>
> Surely that's more work than the issue is worth. It's also inconvenient
> to use, because you'd have to remember to give the swi
On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
> Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
> > Alvaro Herrera writes:
> > > I think it would be better that the schema is specified on the command
> > > line.
> >
> > Surely that's more work than the issue is worth. It's al
Tom Lane wrote:
Andrew Dunstan writes:
I know of at least one significant client (OpenACS) that still
apparently requires extended flavor.
Is this demonstrable, or just speculation? The incompatibilities
between ARE mode and (legal) ERE patterns are pretty darn small.
Alvaro Herrera writes:
> ... Maybe we should make that
> setting PGC_POSTMASTER (or just get rid of it?),
Another thought here: if we do get persuaded that the regex_flavor GUC
has to stay, we could eliminate it as a hazard for planning by changing
its scope to PGC_BACKEND. That would be much l
Andrew Dunstan writes:
> I know of at least one significant client (OpenACS) that still
> apparently requires extended flavor.
Is this demonstrable, or just speculation? The incompatibilities
between ARE mode and (legal) ERE patterns are pretty darn small.
regards, tom
Alvaro Herrera writes:
> I think it would be better that the schema is specified on the command
> line.
Surely that's more work than the issue is worth. It's also inconvenient
to use, because you'd have to remember to give the switch both for the
-i run and the normal test runs.
On Wed, 2009-05-06 at 16:10 -0400, Andrew Dunstan wrote:
> > Isn't that why we wouldn't remove it from back releases?
> >
> >
>
> My clients aren't going to be very happy if they can't upgrade because
> of this.
Certainly. Nobody wants to make clients unhappy but for the good of the
code ma
Joshua D. Drake wrote:
On Wed, 2009-05-06 at 15:55 -0400, Andrew Dunstan wrote:
I know of at least one significant client (OpenACS) that still
apparently requires extended flavor. Removing the compatibility option
would be a major pain point for some of my clients. PGC_POSTMASTER would
b
On Wed, 2009-05-06 at 15:55 -0400, Andrew Dunstan wrote:
> I know of at least one significant client (OpenACS) that still
> apparently requires extended flavor. Removing the compatibility option
> would be a major pain point for some of my clients. PGC_POSTMASTER would
> be fine, though.
Isn't
Tom Lane wrote:
Alvaro Herrera writes:
I think changeable regex flavors turned out to be a bad idea. They can
wreak all sorts of havoc. You change the setting, SIGHUP, and suddenly
your application fails to work as expected. Maybe we should make that
setting PGC_POSTMASTER (or just get
Alvaro Herrera píše v st 06. 05. 2009 v 15:11 -0400:
> Zdenek Kotala wrote:
>
> > If there is not another problem I suggest to use two different locks for
> > vacuum and analyze.
>
> By itself that won't work -- see vac_update_relstats.
It says:
* Note another assumption: that two VACUUMs
On Wed, 2009-05-06 at 15:13 -0400, Alvaro Herrera wrote:
> Dickson S. Guedes wrote:
> > Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
>
> > > Seems like the right policy for that is "run pgbench in its own
> > > database".
> >
> > A text warning about this could be shown at start of pgbe
"Dickson S. Guedes" writes:
> Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
>> Seems like the right policy for that is "run pgbench in its own
>> database".
> A text warning about this could be shown at start of pgbench if the
> target database isn't named "pgbench", for examplo, or just
Zdenek Kotala writes:
> My colleague hit interesting problem. His transaction hanged for a
> several days (PG8.3). We found that transaction (ANALYZE) command)
> waited on relation lock which had been acquired by lazy vacuum.
> Unfortunately, lazy vacuum on large table (38GB) takes vry long ti
Dickson S. Guedes wrote:
> Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
> > Seems like the right policy for that is "run pgbench in its own
> > database".
>
> A text warning about this could be shown at start of pgbench if the
> target database isn't named "pgbench", for examplo, or jus
Zdenek Kotala wrote:
> If there is not another problem I suggest to use two different locks for
> vacuum and analyze.
By itself that won't work -- see vac_update_relstats.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom D
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
> Greg Smith writes:
> > I once did some pgbench testing on a system that included a real
> > "accounts" table in a named schema. "pgbench -i" will execute "drop table
> > if exists accounts". It had already accidentally wiped out the copy
My colleague hit interesting problem. His transaction hanged for a
several days (PG8.3). We found that transaction (ANALYZE) command)
waited on relation lock which had been acquired by lazy vacuum.
Unfortunately, lazy vacuum on large table (38GB) takes vry long time
- several days.
The proble
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If we think there aren't any of those anymore, let's just kill the
> GUC and be done with it.
+1.
I'll try to spend some time in backend/regexp and regex_fixed_prefix
soon.
Thanks,
Stephen
signature.asc
Description: Digital si
Alvaro Herrera writes:
> ... Maybe we should make that
> setting PGC_POSTMASTER (or just get rid of it?), and provide was to pass
> flags to change the flavor for particular operations (this is easy for
> function-based stuff but not so easy for operators).
BTW, if you are putting it on the appli
Tom Lane wrote:
Alvaro Herrera writes:
I think changeable regex flavors turned out to be a bad idea. They can
wreak all sorts of havoc. You change the setting, SIGHUP, and suddenly
your application fails to work as expected. Maybe we should make that
setting PGC_POSTMASTER (or just get rid o
On Wed, May 06, 2009 at 12:10:49PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Stephen Frost writes:
>
> > > Perhaps this is misguided but I would think that the regexp
> > > libraries might have some support for "give me all anchored
> > > required text for this regexp" which we could the
Hi,
On 05/04/2009 04:10 PM, Andres Freund wrote:
Would a patch adding 'IF EXISTS' support to:
- ALTER TABLE ... DROP COLUMN
- ALTER TABLE ... DROP CONSTRAINT
possibly be accepted?
A first version of a patch is attached:
- allows [ IF EXISTS ] for both, conditional dropping of columns and
const
Alvaro Herrera writes:
> I think changeable regex flavors turned out to be a bad idea. They can
> wreak all sorts of havoc. You change the setting, SIGHUP, and suddenly
> your application fails to work as expected. Maybe we should make that
> setting PGC_POSTMASTER (or just get rid of it?), and
Tom Lane wrote:
> Stephen Frost writes:
> > Perhaps this is misguided but I would think that the regexp
> > libraries might have some support for "give me all anchored required
> > text for this regexp" which we could then use in the planner.
>
> I wouldn't see why. It's certainly worth conside
Peter Eisentraut writes:
> For distinguishing various input formats, we could use the backslash
> to escape the format specification without breaking backward
> compatibilty, e.g.,
Oh, you're right! I had been thinking that byteain treats \x as
just meaning x if x isn't an octal digit, but actua
Олег Царев wrote:
Parser translate from text of query to AST.
1) Than AST go to planner for plan normalization and optimization.
Planner work on AST structures, or build self internal tree of logical plan?
The planner works with different structures in different phases of
planning. Some trans
=?KOI8-R?B?78zFxyDjwdLF1w==?= writes:
> I need help in study internal structures of PosrgreSQL. Sorry for my bad
> english.
> I try to get information from source code and spend five days for that, but
> now have many questions and few understanding =(
> Source code it's clear, great commented, bu
On Tuesday 05 May 2009 17:38:33 Tom Lane wrote:
> "Kevin Grittner" writes:
> > Bernd Helmle wrote:
> >> Another approach would be to just dump bytea columns in binary
> >> format only (not sure how doable that is, though).
> >
> > If that's not doable, perhaps a base64 option for bytea COPY?
>
>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> (In particular, I think it's set up to abandon optimization if it
>> sees | anywhere.)
> That's kind of what I figured from the empirical data. My hope was that
> it might be something which could be fixed.
See regex_fixed_prefix
On Wed, May 6, 2009 at 8:02 AM, Andrew Dunstan wrote:
>
>
> Merlin Moncure wrote:
>>
>> On Tue, May 5, 2009 at 4:14 PM, Tom Lane wrote:
>>
>>>
>>> Heikki Linnakangas writes:
>>>
Tom Lane wrote:
>
> I'm thinking plain old pairs-of-hex-digits might be the best
> tradeoff
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I don't see why the last case can't use the index.
>
> The planner's understanding of regexps is far weaker than yours.
>
> (In particular, I think it's set up to abandon optimization if it
> sees | anywhere.)
That's kind of w
Stephen Frost writes:
> I don't see why the last case can't use the index.
The planner's understanding of regexps is far weaker than yours.
(In particular, I think it's set up to abandon optimization if it
sees | anywhere.)
regards, tom lane
--
Sent via pgsql-hackers
Hello all!
I need help in study internal structures of PosrgreSQL. Sorry for my bad
english.
I try to get information from source code and spend five days for that, but
now have many questions and few understanding =(
Source code it's clear, great commented, but studing so difficult system as
DBMS
Greetings,
I've run into an annoying issue which I would think could be handled
better. Basically, indexes using text_pattern_ops don't work with
some complex regexps even when they (imv anyway) could. I'm willing
to believe I'm wrong about the potential to use them, or that my
regexp
Andrew Dunstan wrote:
another nit with base64 is that properly encoded data requires
newlines according to the standard.
er, no, not as I read rfc 3548 s 2.1.
cheers
andrew
Why does encode('my text', 'base64') include newlines in its output? I
think MIME requires text to be broken i
Andrew Dunstan writes:
> Bernd Helmle wrote:
>> I'm dumb: I don't understand why a hex conversion would be
>> significantly faster than what we have now?
> Quite apart from anything else you would not need the current loop over
> the bytea input to calculate the result length - in hex it would
Greg Smith writes:
> I once did some pgbench testing on a system that included a real
> "accounts" table in a named schema. "pgbench -i" will execute "drop table
> if exists accounts". It had already accidentally wiped out the copy of
> the accounts table on the system during an earlier test,
On Wed, May 6, 2009 at 9:04 AM, Dawid Kuroczko wrote:
> On Wed, May 6, 2009 at 7:22 AM, Asko Oja wrote:
>> It was just yesterday when i wondering why we don't have this feature (i was
>> trying to use it and it wasn't there :).
>> The group of people who think it's unsafe should not use the featu
On Wed, May 6, 2009 at 7:22 AM, Asko Oja wrote:
> It was just yesterday when i wondering why we don't have this feature (i was
> trying to use it and it wasn't there :).
> The group of people who think it's unsafe should not use the feature.
> Clearly this feature would be useful when managing lar
Merlin Moncure wrote:
On Tue, May 5, 2009 at 4:14 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
I'm thinking plain old pairs-of-hex-digits might be the best
tradeoff if conversion speed is the criterion.
That's a lot less space-efficient than base6
On Tue, May 5, 2009 at 4:14 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> I'm thinking plain old pairs-of-hex-digits might be the best
>>> tradeoff if conversion speed is the criterion.
>
>> That's a lot less space-efficient than base64, though.
>
> Well, base64 could gi
Bernd Helmle wrote:
--On Dienstag, Mai 05, 2009 16:57:50 -0400 Andrew Dunstan
wrote:
Hex will already provide some space savings over our current encoding
method for most byteas anyway. It's not like we'd be making things less
efficient space-wise. And in compressed archives the space diffe
--On Dienstag, Mai 05, 2009 20:25:54 -0400 Alvaro Herrera
wrote:
Not that I know of (and yes, this sucks).
But doesn't this also apply to triggers? I can't think of a reliable way to
distinguish specified or unspecified fields in trigger functions as
wellmaybe fiddling with DEFAULT exp
I had a deeper look into $subject. As Tom already noted in [1], this can't
be done by simply issueing a reset message to the stats collector. TRUNCATE
is transactional and can be rolled back. This is becoming more problematic,
if someone is using SAVEPOINTs or is going to fill a previously trunc
--On Dienstag, Mai 05, 2009 16:57:50 -0400 Andrew Dunstan
wrote:
Hex will already provide some space savings over our current encoding
method for most byteas anyway. It's not like we'd be making things less
efficient space-wise. And in compressed archives the space difference is
likely to diss
56 matches
Mail list logo
