Hannu Krosing <[EMAIL PROTECTED]> writes:
> Before this patch, pl/python will not do the right thing if OUT
> parameters are present
Applied with minor stylistic corrections.
I notice that plpython still doesn't like multiple OUT parameters,
but at least it throws a sane error ...
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
blo
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> FWIW pg_dump has fmtId() which does something related.
> I think it's a bit bogus to be using the list as compiled client-side,
> precisely due to the theoretical chance that it could change from one
> server version to the next, but it's probably not v
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch allows dynamic queries in RETURN QUERY statement.
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg01180.php
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgre
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
! print O "#define RELSEG_SIZE ",
! (1024 / $self->{options}->{blocksize}) *
! $self->{options}->{segsize} * 1024, "\n";
This doesn't look quite right; unless the arithmetic is being done in
floating poi
Dave Page wrote:
> Hi,
>
> The attached patch implements a new function, pg_get_keywords(), which
> returns a set of records describing the keywords recognised by the
> server. This allows clients such as pgAdmin to get quoting rules
> correct, and helps with other tasks such as syntax highlightin
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This doesn't look quite right; unless the arithmetic is being done in
>> floating point? I had it like this in configure.in:
>>
>> RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
> blocksize is one of (1,2,4,8
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/5/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
>> How about taking a completely different strategy, and implement the
>> CASE-WHEN construct fully natively in plpgsql, instead of trying to convert
>> it to a single SQL CASE-WHEN expression? It's not a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ! print O "#define RELSEG_SIZE ",
> ! (1024 / $self->{options}->{blocksize}) *
> ! $self->{options}->{segsize} * 1024, "\n";
This doesn't look quite right; unless the arithmetic is being done
Tom Lane wrote:
However, all the values are hardcoded, so nothing in it should relate to
settings that come from configure, I believe. These should be dealt with
in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> This patch adds a GUC parameter for tuple_fraction of cursors (discussed
> earlier here:
> http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php).
> By setting this parameter the planner's favor to use fast-start plans
> for cursors can b
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> You're right - that's just a typo in the subject of the post.
> It's called cursor_tuple_fraction in the submitted patch.
Ah, I hadn't actually read the patch yet ;-). As penance for the noise,
I will do so now.
regards, tom l
Hi,
The attached patch implements a new function, pg_get_keywords(), which
returns a set of records describing the keywords recognised by the
server. This allows clients such as pgAdmin to get quoting rules
correct, and helps with other tasks such as syntax highlighting where
we need to support mu
On Fri, 2008-05-02 at 16:36 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > OK, if that's the view then the patch is ready for commit, AFAICS.
>
> Use of the plural in the name seems a bit odd to me. Anyone have a
> problem with calling it "cursor_tuple_fraction" instead?
Ag
You're right - that's just a typo in the subject of the post.
It's called cursor_tuple_fraction in the submitted patch.
Regards,
Robert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Freitag, 02. Mai 2008 22:36
To: Simon Riggs
Cc: Heikki Linnakangas; Hell, Robert; pgs
Simon Riggs <[EMAIL PROTECTED]> writes:
> OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem with calling it "cursor_tuple_fraction" instead?
regards, tom lane
--
Sent via pgsql-p
"Mark Wong" <[EMAIL PROTECTED]> writes:
> I saw a that a patch was committed that exposed a configure switch for
> BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ. I
> think I got the configure.in, sgml, pg_config_manual.h, and
> pg_config.h.in changes correct.
Applied with minor
On Fri, May 2, 2008 at 9:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mark Wong" <[EMAIL PROTECTED]> writes:
>
> > I still believe it makes sense to have them separated. I did have
> > some data, which has since been destroyed, that suggested there were
> > some system characterization differen
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
> I see this as being basically another cost parameter, and as such
> I don't think it needs more documentation than any of those have.
> (Now admittedly you could argue that they could all use a ton more
> documentation than they now have, but it
On Fri, 2008-05-02 at 16:17 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > * We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
> > "Don't want hints". If that's what we really think, then this patch must
> > surely be rejected because its a hint... That isn't my view.
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> * We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
> >> "Don't want hints". If that's what we really think, then this patch must
> >> surely be reje
On Fri, 2 May 2008, Tom Lane wrote:
The case for varying BLCKSZ is marginal already, and I've seen none at
all for varying XLOG_BLCKSZ.
I recall someone on the performance list who felt it useful increase
XLOG_BLCKSZ to support a high-write environment with WAL shipping, just to
make sending
On Fri, 2 May 2008 09:12:32 -0700
"Mark Wong" <[EMAIL PROTECTED]> wrote:
> I still believe it makes sense to have them separated. I did have
> some data, which has since been destroyed, that suggested there were
> some system characterization differences for OLTP workloads with
> PostgreSQL. Le
"Mark Wong" <[EMAIL PROTECTED]> writes:
> I still believe it makes sense to have them separated. I did have
> some data, which has since been destroyed, that suggested there were
> some system characterization differences for OLTP workloads with
> PostgreSQL. Let's hope those disks get delivered
On Fri, May 2, 2008 at 8:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mark Wong" <[EMAIL PROTECTED]> writes:
>
> > As someone who has tested varying both those parameters it feels
> > awkward to have a configure option for one and not the other, or vice
> > versa. I have slightly stronger feeli
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> * We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
>> "Don't want hints". If that's what we really think, then this patch must
>> surely be rejected because its a hint... That isn't my view. I *now*
>> thi
"Mark Wong" <[EMAIL PROTECTED]> writes:
> As someone who has tested varying both those parameters it feels
> awkward to have a configure option for one and not the other, or vice
> versa. I have slightly stronger feelings for having them both as
> configure options because it's easier to script, b
On Fri, May 2, 2008 at 12:04 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> Tom Lane wrote:
>
> > "Mark Wong" <[EMAIL PROTECTED]> writes:
> >
> > > I saw a that a patch was committed that exposed a configure switch for
> > > BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
> > >
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
"Don't want hints". If that's what we really think, then this patch must
surely be rejected because its a hint... That isn't my view. I *now*
think we do need hints of various kinds.
cursors_tuple_fracti
On Thu, 2008-04-03 at 16:45 +0200, Hell, Robert wrote:
> This patch adds a GUC parameter for tuple_fraction of cursors (discussed
> earlier here:
> http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php).
> By setting this parameter the planner's favor to use fast-start plans
> for c
On Fri, May 2, 2008 at 10:31 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> George Gensure escribió:
>
>
> > So if nobody's got any further objections, could this patch be applied?
>
> It's in the queue:
>
> http://wiki.postgresql.org/wiki/CommitFest:May
>
> --
>
>
> Alvaro Herrera
George Gensure escribió:
> So if nobody's got any further objections, could this patch be applied?
It's in the queue:
http://wiki.postgresql.org/wiki/CommitFest:May
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
On Wed, Apr 30, 2008 at 12:58 PM, George Gensure <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
>
>
> > George Gensure escribió:
> >
> >
> > > I've done a quick write up for reload time reporting from the
> > > administration TODO. I
Hello
2008/5/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>
>> Hello
>>
>> I found some bugs when I used base_lexer, so I returned back own
>> lexer. It's only little bit longer, but simpler.
>
> Hmm. I don't like having to lex the expressions again. It just doesn't feel
> rig
Pavel Stehule wrote:
Hello
I found some bugs when I used base_lexer, so I returned back own
lexer. It's only little bit longer, but simpler.
Hmm. I don't like having to lex the expressions again. It just doesn't
feel right.
How about taking a completely different strategy, and implement the
Tom Lane wrote:
"Mark Wong" <[EMAIL PROTECTED]> writes:
I saw a that a patch was committed that exposed a configure switch for
BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
Well, we certainly *could*, but what's the use-case really? The case
for varying BLCKSZ is marginal a
36 matches
Mail list logo
