On Fri, Feb 20, 2009 at 7:25 PM, decibel wrote:
> On Feb 17, 2009, at 11:23 PM, Robert Haas wrote:
>>>
>>> Actually, a simple algorithm that might work really well would be to
>>> calculate relation cache odds as ( number of page accesses for relation /
>>> number of page accesses for all relation
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
There is an unfinished TODO item here: we really ought to make it work
for tar-format archives. That's probably not hugely difficult, but
I didn't look into it, and don't think we should hold up applying the
existing patch for i
On Feb 17, 2009, at 11:23 PM, Robert Haas wrote:
Actually, a simple algorithm that might work really well would be to
calculate relation cache odds as ( number of page accesses for
relation /
number of page accesses for all relations ) * ( sum(relpages)*BLKSZ /
eff_cache_size ), where number o
On Wed, 18 Feb 2009, Kris Jurka wrote:
I have reviewed pljava's handling of misrepresented alignment, length, and by
value parameters [and it doesn't all work.]
I have fixed pljava to now correctly handle all of these being defined
incorrectly. So a trusted language can be used to create
Merlin Moncure writes:
> On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane wrote:
>> Use "select * from ..." instead.
> Yeah...I was thinking maybe that shouldn't be required:
If you allow both interpretations then you create a syntactic ambiguity
(at least for the case of single-column composite types
On Fri, Feb 20, 2009 at 3:25 PM, Merlin Moncure wrote:
> On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> create table foo(a int, b int);
>>> postgres=# create function rfoo() returns setof foo as $$ begin return
>>> query select foo from foo; end; $$ language plpgs
On Fri, Feb 20, 2009 at 3:00 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> create table foo(a int, b int);
>> postgres=# create function rfoo() returns setof foo as $$ begin return
>> query select foo from foo; end; $$ language plpgsql;
>
> Use "select * from ..." instead.
Yeah...I was thinkin
Merlin Moncure writes:
> create table foo(a int, b int);
> postgres=# create function rfoo() returns setof foo as $$ begin return
> query select foo from foo; end; $$ language plpgsql;
Use "select * from ..." instead.
regards, tom lane
--
Sent via pgsql-hackers mailing
create table foo(a int, b int);
postgres=# create function rfoo() returns setof foo as $$ begin return
query select foo from foo; end; $$ language plpgsql;
CREATE FUNCTION
Time: 25.606 ms
postgres=#
postgres=#
postgres=# select rfoo();
ERROR: structure of query does not match function result type
On Fri, 2009-02-20 at 11:57 -0600, Kevin Grittner wrote:
>
> > But you are right that there isn't a simple formula.
>
> Perhaps the greater of the number of CPUs or effective spindles?
>
> (24 sounds suspiciously close to effective spindles on a 50 spindle
> box
> with RAID 10.)
It does exce
>>> Andrew Dunstan wrote:
> Joshua D. Drake wrote:
>> the fastest restore time for
>> 220G was performed with 24 threads with an 8 core box.
>> It is important to point out that this was a machine with 50
spindles.
>> Which is where your bottleneck is going to be immediately after
solving
>> th
On Fri, Feb 20, 2009 at 09:22:58AM -0800, Joshua D. Drake wrote:
> On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
>
> > The short answer is that we don't know yet. There is anecdotal evidence
> > that the number of CPUs on the server is a good place to start, but we
> > should be hones
Joshua D. Drake wrote:
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
The short answer is that we don't know yet. There is anecdotal evidence
that the number of CPUs on the server is a good place to start, but we
should be honest enough to say that this is a new feature and we a
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
> The short answer is that we don't know yet. There is anecdotal evidence
> that the number of CPUs on the server is a good place to start, but we
> should be honest enough to say that this is a new feature and we are
> still gathering in
On Fri, Feb 20, 2009 at 10:59 AM, Tom Lane wrote:
> I wrote:
>> Hence semijoins can be rearranged just as freely as inner joins.
>
> I guess nobody checked my work, because that claim is bogus.
I spent some time reading your email and thinking through the cases,
but I completely failed to notice
I wrote:
> Hence semijoins can be rearranged just as freely as inner joins.
I guess nobody checked my work, because that claim is bogus. Consider
A semijoin (B innerjoin C on (Pbc)) on (Pab)
=? (A semijoin B on (Pab)) innerjoin C on (Pbc)
In the second form the inner join is now
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run
simultaneously. If the -j
option is given without an argument, pg_restore will not limit the
number of
jobs that can run simultaneously.
Pavel Stehule writes:
>> Curiously enough, Oracle has it so that || of null arguments treats the
>> arguments as empty string.
>>
>> It's beyond comprehension.
>>
> what is result of '' || '' ?
Well the result of this is NULL of course (which is the same as '')
What's more puzzling is what the
> Curiously enough, Oracle has it so that || of null arguments treats the
> arguments as empty string.
>
> It's beyond comprehension.
>
what is result of '' || '' ?
Pavel
> But yeah, a varchar2 type with a full set of functions and operators could
> work. If you choose not to bother with support
On Thu, 19 Feb 2009, Andrew Dunstan wrote:
Date: Thu, 19 Feb 2009 21:58:18 -0500
From: Andrew Dunstan
To: Tom Lane
Cc: o...@pyrenet.fr, pgsql-hackers list
Subject: Re: [HACKERS] pg_restore new option -m
Tom Lane wrote:
o...@pyrenet.fr writes:
pg_restore -C -m 4 -d template1 db.dmp
gives
Tom Lane wrote:
How about introducing a "varchar2" type as in Oracle?
Maybe. I think right now we don't allow input functions to decide
that a non-null input string should be converted to a NULL, but
that might be fixable. It'd still be an ugly mess though, since
I suspect you'd have to intro
I was revisiting the issue of how to prevent psql from prompting for a
password, for batch operations, previously discussion here:
http://www.mail-archive.com/pgsql-b...@postgresql.org/msg18440.html
http://www.mail-archive.com/pgsql-b...@postgresql.org/msg20002.html
I noticed that there appear
Teodor Sigaev wrote:
Right, can't do that on a hot standby server.
Is anywhere applicable hot standby patch? Last version on wiki is 9g and
it can't be applied cleanly.
The latest version is in Simon's git repository at:
http://git.postgresql.org/?p=~sriggs/simon.git;a=shortlog;h=refs/heads
Tom Lane wrote:
Couldn't you get rid of PMSIGNAL_RECOVERY_COMPLETED altogether? If the
startup process exits with code 0, recovery is complete, else there
was trouble. I find this SetPostmasterSignal bit quite ugly anyway.
Right now, the startup process exits with code 0 also when it's told t
Andrew Dunstan wrote:
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run simultaneously.
If the -j
option is given without an argument, pg_restore will not limit the
number of
jobs that can run simultaneously.
Quite apart from anything e
Right, can't do that on a hot standby server.
Is anywhere applicable hot standby patch? Last version on wiki is 9g and it
can't be applied cleanly.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.s
Jacky Leng wrote:
Asserts on data-consistency checks aren't really a good idea.
(IOW this is "can't happen" only as long as your database isn't
corrupt...)
Then why not change this to an "ereport(PANIC ...)"?
If you have a corrupted database, you want to be able to read it, not
panic. If
Peter Eisentraut wrote:
> ITAGAKI Takahiro wrote:
> > Here is a patch to allow 'on' and 'off' as input texts for boolean.
>
> Regarding your FIXME comment, I think parse_bool* should be in bool.c
> and declared in builtins.h, which guc.c already includes.
> (Conceptually, the valid format of
> Asserts on data-consistency checks aren't really a good idea.
>
> (IOW this is "can't happen" only as long as your database isn't
> corrupt...)
>
Then why not change this to an "ereport(PANIC ...)"?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
29 matches
Mail list logo
