James William Pye <[EMAIL PROTECTED]> writes:
> In PL/Py, I had the bright idea of storing bytecode in the probin field of the
> function's pg_proc row. However, this idea has lately become rather dim as I
> have recently rediscovered(thanks Adrian) that this breaks dumps; pg_dump
> outputs
> a PL
I wrote:
> We can use the same technique that we used for UNION JOIN, but instead
> join, say, WITH and TIME into one token and make the time datatype
> productions look for "TIME WITHTIME ZONE" and so on. (I propose this
> rather than putting the ugliness into WITH CHECK OPTION, because this
> wa
Hi,
In PL/Py, I had the bright idea of storing bytecode in the probin field of the
function's pg_proc row. However, this idea has lately become rather dim as I
have recently rediscovered(thanks Adrian) that this breaks dumps; pg_dump
outputs
a PL/Py function as "CREATE FUNCTION x() RETURNS y LANG
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, I just read the same in the bison manual. The thing that's
>> bothering me is that a GLR parser would hide that ambiguity from you,
> It doesn't really hide it. You still get the "N shift/reduce conflicts"
> warnings from b
Tom Lane wrote:
> Yeah, I just read the same in the bison manual. The thing that's
> bothering me is that a GLR parser would hide that ambiguity from you,
It doesn't really hide it. You still get the "N shift/reduce conflicts"
warnings from bison. You just know that they are being handled.
--
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> As I understand it, it runs one parser pretty much like the standard LALR(1)
> case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which
> stage it clones the parser to take parallel paths, working in lockstep, and
> storing up semanti
Tom Lane said:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> "The GLR parsers require a compiler for ISO C89 or later. In
>>> addition, they use the inline keyword, which is not C89, but is C99
>>> and is a common extension in pre-C99 compilers. It is up to the user
>>
On Friday 26 May 2006 09:45, Gurjeet Singh wrote:
> Something not supported should be stated as such through an ERROR. Except
> for count(), none of the following make any sense:
>
> The transcipt:
>
> test=# \d t1
> Table "public.t1"
> Column | Type | Modifiers
> +-+--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> "The GLR parsers require a compiler for ISO C89 or later. In
>> addition, they use the inline keyword, which is not C89, but is C99
>> and is a common extension in pre-C99 compilers. It is up to the user
>> of these parsers to
Greg Stark <[EMAIL PROTECTED]> writes:
> And indeed in pg_type the typalign column says "i" for this data type. My
> question is just, why? What would be the problem with an alignment of 1 for
> "name"?
Probably none, but that's how it's been defined since day one, and there
doesn't seem any good
> On Thu, May 25, 2006 at 08:41:17PM -0300, Rodrigo Hjort wrote:
>> >
>> >I think more exactly, the planner can't possibly know how to plan an
>> >indexscan with a leading '%', because it has nowhere to start.
>> >
>>
>> The fact is that index scan is performed on LIKE expression on a string
>> not
I wrote:
> I'm off for a little visit with oprofile...
It seems the answer is that fwrite() does have pretty significant
per-call overhead, at least on Fedora Core 4. The patch I did yesterday
still ended up making an fwrite() call every few characters when dealing
with bytea text output, because
Andrew Dunstan wrote:
> "The GLR parsers require a compiler for ISO C89 or later. In
> addition, they use the inline keyword, which is not C89, but is C99
> and is a common extension in pre-C99 compilers. It is up to the user
> of these parsers to handle portability issues."
We already use inline,
Peter Eisentraut said:
> Martijn van Oosterhout wrote:
>> Incidently, IIRC the default behaviour on conflict is a shift anyway,
>> so that what the patch already does anyway.
>>
>> So we get:
>>
>> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
>> CREATE VIEW foo AS SELECT expr
Martijn van Oosterhout wrote:
> Incidently, IIRC the default behaviour on conflict is a shift anyway,
> so that what the patch already does anyway.
>
> So we get:
>
> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
> CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION <
In c.h There is the following comment:
/*
* We want NameData to have length NAMEDATALEN and int alignment,
* because that's how the data type 'name' is defined in pg_type.
* Use a union to make sure the compiler agrees. Note that NAMEDATALEN
* must be a multiple of sizeof(int), else sizeof(N
On Fri, May 26, 2006 at 04:41:51PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > There is a noticeable rise in sort time with increasing work_mem, but
> > that needs to be offset from the benefit that in-general comes from
> > using a large Heap for the sort. With the data yo
Simon Riggs <[EMAIL PROTECTED]> writes:
> There is a noticeable rise in sort time with increasing work_mem, but
> that needs to be offset from the benefit that in-general comes from
> using a large Heap for the sort. With the data you're using that always
> looks like a loss, but that isn't true wi
On Fri, 2006-05-26 at 14:47 -0500, Jim C. Nasby wrote:
> But the meat is:
> -- work_mem --
> Scale 20002
> not compressed 150 805.7 797.7
> not compressed 300017820 17436
Andreas Seltenreich schrob:
> Teodor Sigaev schrob:
>
>> Thanks a lot, applied. Can you describe test suite? It may be useful
>> for test more...
>
> Here's a shell script that triggers the bug when I revert the patch.
Just tried the script on HEAD, and it was triggering an assertion. I
guess it
On Fri, May 26, 2006 at 10:59:37AM +0100, Simon Riggs wrote:
> Not sure what the edit commands are offhand, but we would need the
> following program:
>
> - edit postgresql.conf
> - pg_reload_conf()
> - wait 30
> - pg_start_backup('blah')
Rather than 'wait 30', ISTM it would be better to just lea
I wrote:
> I can't test psql binary \copy just yet, but will look at applying your
> recent patch so that case can be checked.
With patch applied:
$ time psql -c "\\copy t to '/home/tgl/t.out2'" bytea
real3m46.057s
user0m2.724s
sys 0m36.118s
$ time psql -c "\\copy t to '/home/tgl/t.o
On Fri, May 26, 2006 at 12:15:34AM +0200, Andreas Pflug wrote:
> Jim Nasby wrote:
> >Another consideration is that you can use rsync to update a
> >filesystem-level backup, but there's no pg_dump equivalent. On a large
> >database that can make a sizable difference in the amount of time
> >requi
Originally I wanted the command to be a string, and archiving to be a
boolean, but Tom wanted a single parameter, and others agreed.
---
Andreas Pflug wrote:
> Simon Riggs wrote:
> > On Thu, 2006-05-25 at 17:25 +0200, Andrea
On Fri, May 26, 2006 at 12:35:36PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Something else worth mentioning is that sort performance is worse with
> > larger work_mem for all cases except the old HEAD, prior to the
> > tuplesort.c changes. It looks like whatever was d
Teodor Sigaev schrob:
> Thanks a lot, applied. Can you describe test suite? It may be useful
> for test more...
Here's a shell script that triggers the bug when I revert the patch.
regards,
andreas
#!/bin/sh
set -x
set -e
PGPORT=5434
CLUSTER="gintest/"
ARCHIVE="gintest-archive/"
[ -d "$ARCHI
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> My concern is that it's not inconceiveable to typo max(field) into
> max(*), which could make for a rather frustrating error. Not to mention
> this being something that could trip newbies up. If nothing else I'd say
> it warrants a %TODO just so it doesn
On Fri, May 26, 2006 at 14:06:29 -0500,
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> But if aggregate(*) just gets turned into aggregate(1) by the backend,
> why not just tell people to use aggregate(1) for their custom
> aggregates? Or am I misunderstanding how aggregate(*) is actually
> handl
On Fri, May 26, 2006 at 11:03:17AM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
> >> Shouldn't
> >> SELECT max(*) FROM foo;
> >> give an error?
>
> > Doesn't seem an important or even useful extension of the standa
On Thu, May 25, 2006 at 08:23:53PM -0400, Dave wrote:
> could CREATE TYPE be used to make a case insensitive version of varchar?
> So that doing something like LOWER(username) = 'joe' could just be done
> like username = 'joe' ?
>
> I want to try to avoid using CREATE TYPE with C extensions and
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Here are the results, with the copy patch:
psql \copy 1.4 GB from table, binary:
8.0 8.1 8.2dev
36s 34s 36s
psql \copy 6.6 GB from table, std:
8.0 8.1 8.2dev
375s362s290s (second:283s)
Hmph. Th
Martijn van Oosterhout writes:
> So we get:
>
> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
> CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION <-- parse error
> CREATE VIEW foo AS SELECT (expr :: TIME) WITH CHECK OPTION <-- OK
I haven't really been followi
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Here are the results, with the copy patch:
> psql \copy 1.4 GB from table, binary:
> 8.0 8.1 8.2dev
> 36s 34s 36s
> psql \copy 6.6 GB from table, std:
> 8.0 8.1 8.2dev
> 375s 362s290s (second:283s)
Hmph. There's something strang
could CREATE TYPE be used to make a case insensitive version of varchar?
So that doing something like LOWER(username) = 'joe' could just be done
like username = 'joe' ?
I want to try to avoid using CREATE TYPE with C extensions and using a
new operator all over the place is not an option... Ho
On Fri, May 26, 2006 at 11:38:41AM -0500, Jim C. Nasby wrote:
> > select * from table where field like 'THE NAME%'; -- index scan
> > select * from table where field like '%THE NAME%'; -- seq scan
> > select * from table where field like :bind_param; -- seq scan (always)
>
> How difficult would it
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Something else worth mentioning is that sort performance is worse with
> larger work_mem for all cases except the old HEAD, prior to the
> tuplesort.c changes. It looks like whatever was done to fix that will
> need to be adjusted/rethought pending the o
On Thu, May 25, 2006 at 08:41:17PM -0300, Rodrigo Hjort wrote:
> >
> >I think more exactly, the planner can't possibly know how to plan an
> >indexscan with a leading '%', because it has nowhere to start.
> >
>
> The fact is that index scan is performed on LIKE expression on a string not
> precede
I've done some more testing with Tom's recently committed changes to
tuplesort.c, which remove the tupleheaders from the sort data. It does
about 10% better than compression alone does. What's interesting is that
the gains are about 10% regardless of compression, which means
compression isn't helpi
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Looking at CopySendData, I wonder whether any traction could be gained
by trying not to call fwrite() once per character. I'm not sure how
much per-call overhead there is in that function. We've done a lot of
work try
On Wed, May 24, 2006 at 01:13:06PM +0200, Peter Eisentraut wrote:
> CREATE VIEW foo AS SELECT expr :: TIME . WITH
>
> (where expr is a_expr or b_expr and TIME could also be TIMESTAMP or TIME(x)
> or
> TIMESTAMP(x)).
>
> The continuation here could be WITH TIME ZONE (calling for a shift) or WITH
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
>> Shouldn't
>> SELECT max(*) FROM foo;
>> give an error?
> Doesn't seem an important or even useful extension of the standard, but
> would probably require special case processing for every aggre
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I had a quick look - I don't think there is an easy answer with the
> current proposed grammar. If we want to prevent shift/reduce conflicts I
> suspect we'd need to use a different keyword than WITH, although I can't
> think of one that couldn't be a
Peter Eisentraut wrote:
Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
I have spent some time figuring out how to resolve the parsing conflicts
in Bernd Helmle's updatable views patch. The problem has now been
reduced to specifically this
On Fri, May 26, 2006 at 05:16:59PM +0300, Marko Kreen wrote:
> On 5/26/06, Martijn van Oosterhout wrote:
> >On Fri, May 26, 2006 at 08:21:56AM +0200, Hans-Jürgen Schönig wrote:
> >> I got a bug request for the following unicode character in PostgreSQL
> >> 8.1.4: 0xedaeb8
> >>
> >> ERROR: invalid
=?windows-1252?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> But the code does a check where the second character should not be
> greater than 0x9F, when first character is 0xED. This is not according
> to UTF-8 standard in RFC 3629.
Better read the RFC again: it says
UTF8-3
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I'm not sure you can expect that to work. The system is not built to
guarantee instantaneous response to mode changes like that.
Um, as long as xlog writing stops immediate recycling when
pg_start_backup is execute
On 5/26/06, Martijn van Oosterhout wrote:
On Fri, May 26, 2006 at 08:21:56AM +0200, Hans-Jürgen Schönig wrote:
> I got a bug request for the following unicode character in PostgreSQL
> 8.1.4: 0xedaeb8
>
> ERROR: invalid byte sequence for encoding "UTF8": 0xedaeb8
Your character converts to c
On Fri, May 26, 2006 at 08:21:56AM +0200, Hans-Jürgen Schönig wrote:
> good morning,
>
> I got a bug request for the following unicode character in PostgreSQL
> 8.1.4: 0xedaeb8
>
> ERROR: invalid byte sequence for encoding "UTF8": 0xedaeb8
>
> This one seemed to work properly in PostgreSQL 8.0
On 5/26/06, Simon Riggs <[EMAIL PROTECTED]> wrote:> On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
> > Shouldn't> >> >SELECT max(*) FROM foo;
> >> > give an error?IMO, yes.> > SQL:2003 would not allow this; SQL:2003 permits only COUNT(*) and no> other aggregate function. All other a
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure you can expect that to work. The system is not built to
>> guarantee instantaneous response to mode changes like that.
> Um, as long as xlog writing stops immediate recycling when
> pg_start_backup is executed everything
On Wed, May 24, 2006 at 09:13:42PM -0400, Tom Lane wrote:
> The zic database doesn't seem to have a problem with using the same
> abbreviations to mean many different things. We could look to it for
> information, or maybe even use its classification of timezone groups,
> but I don't think it can
On Wed, May 24, 2006 at 05:45:57PM -0700, Richard wrote:
> /usr/local/pgsql/bin > ls -al postmaster
> lrwxrwx--- 1 root wheel 8 2006-05-24 07:48 postmaster -> postgres
How did that happen. I was always under the impression that permission
bits on symbolic links were ignored, and chmod on my
On Fri, 2006-05-26 at 12:38 +0200, Andreas Pflug wrote:
> Editing postgresql.conf for this is ugly.
That seems to be the real issue here, not archiving. All you need to do
is to set and unset a parameter, that's all.
We're agreed that your end goal is worthwhile, but not on the mechanism
for ac
Simon Riggs wrote:
On Thu, 2006-05-25 at 17:25 +0200, Andreas Pflug wrote:
Currently, I have to
edit postgresql.conf and SIGHUP to "turn on archiving" configuring a
(hopefully) writable directory, do the backup, edit postgresql.conf and
SIGHUP again. Not too convenient...
You're doing
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
That's right, but my proposal would implicitely switch on archiving
while backup is in progress, thus explicitely enabling/disabling
archiving wouldn't be necessary.
I'm not sure you can expect that to work. The system is not built
On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
> Shouldn't
>
>SELECT max(*) FROM foo;
>
> give an error?
SQL:2003 would not allow this; SQL:2003 permits only COUNT(*) and no
other aggregate function. All other aggregates require a value
expression.
> Instead it's executed like
On Thu, 2006-05-25 at 17:25 +0200, Andreas Pflug wrote:
> Tom Lane wrote:
> > Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >>I propose to introduce a GUC "permanent_archiving" or so, to select
> >>whether wal archiving happens permanently or only when a backup is in
> >>progress (i.e. between
Shouldn't
SELECT max(*) FROM foo;
give an error? Instead it's executed like
SELECT max(1) FROM foo;
Just like count(*) is executed as count(1).
Something for the TODO or is it a feature?
ps. I know it's not an important case since no one sane would try to
calculate max(*), but still.
Thanks a lot, applied. Can you describe test suite? It may be useful for test
more...
GIN is young code and it needs to independently tests.
Andreas Seltenreich wrote:
I'm just experimenting a bit with GIN, and it is occasionally getting
stuck looping in findParents() during WAL replay.
--
Te
Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I have spent some time figuring out how to resolve the parsing conflicts
> > in Bernd Helmle's updatable views patch. The problem has now been
> > reduced to specifically this situation:
>
> Could
60 matches
Mail list logo
