On Thu, Jan 1, 2009 at 22:44, Alex Hunsaker wrote:
> Looking at the patch we dont compress things > 1M anymore so I thought
> maybe I was hitting that. But no luck there are only 39 rows where
> the row size > 1M... With those 39 being about 22M each.
Oh my... 25 * 40 = 1000M
So I guess my qu
On Thu, Jan 01, 2009 at 11:10:38PM +0200, Martin Pihlak wrote:
> Peter Eisentraut wrote:
> > Well, what this function essentially does is a text transformation of the
> > options, something like this:
> >
> > peter=# SELECT array_to_string(fdwoptions || srvoptions || umoptions, ' ')
> > FROM pg_
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker wrote:
> My hunch is its related to
> http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
> or for the CVS inclined
> http::/archives.postgresql.org/pgsql-committers/2008-03/msg00121.php
>
> But if anything tha
On Thu, Jan 1, 2009 at 11:49 PM, Greg Stark wrote:
> Sorry for top-posting -- phone mail client sucks.
>
> I thought the autoconf ac_run_check was the test that people were
> questioning. That calls posix_fadvise to see if it crashes at configure
> time.
Yes, that's what I removed.
> The guc run
Sorry for top-posting -- phone mail client sucks.
I thought the autoconf ac_run_check was the test that people were
questioning. That calls posix_fadvise to see if it crashes at
configure time.
The guc run-time check is checking for known-buggy versions of glibc
using sysconf to check wha
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker wrote:
> http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cdbits
... typoed that its
http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
--
Sent via pgsql-hackers m
I just did a fresh import of my alpha database into 8.4 and noticed
that the size of the database had increased significantly:
8.4: 6.3G
8.3: 4.9G
Tracking it down the main difference seems to a toast tables namely this one:
ls -ltrh 8.3/base/16516/430156
-rw--- 1 postgres postgres 145M 2009
> Now that there's an actual run-time sysconf check for the buggy glibc called
> by the guc function we arguably don't need the autoconf check_run check
> anymore anyways.
Isn't that the check I just removed for you, or are you talking about
some other check that can also be removed?
...Robert
-
On Tue, Dec 30, 2008 at 12:29 AM, Bryce Cutt wrote:
> Here is the next patch version.
Thanks for posting this update. This is definitely getting better,
but I still see some style issues. We can work on fixing those once
the rest of the details have been finalized.
However, one question in thi
On Thursday 01 January 2009 15:28:51 Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Thu, 2009-01-01 at 14:47 -0500, Bruce Momjian wrote:
> > > Andrew Chernow wrote:
> > > > Bruce Momjian wrote:
> > > > > Greg Stark wrote:
> > > > >> Is that actually legal if we haven't modified the files? Or
In theory there should be no benefit on a single spindle system. There
could be a slight benefit due to reordering of I/o but only on a raid
array would you see a significant speedup -- which should be about
equal to the number of spindles.
What would be interesting is whether you see a not
On Thu, Jan 1, 2009 at 19:59, Tom Lane wrote:
> I wrote:
>> * in an EXEC_BACKEND situation, we re-execute
>> process_shared_preload_libraries() when starting a fresh backend
>> (but not in other kinds of child processes, which is why the other
>> problem is a problem). This means re-executing the
I wrote:
> * in an EXEC_BACKEND situation, we re-execute
> process_shared_preload_libraries() when starting a fresh backend
> (but not in other kinds of child processes, which is why the other
> problem is a problem). This means re-executing the _PG_init function,
> which will try to redefine the
On Thu, Jan 1, 2009 at 17:28, Tom Lane wrote:
> "Alex Hunsaker" writes:
>> ... So Im going to mark it as
>> ready for commmiter.
>
> Has this patch been tested on Windows? (Or more generally, with
> EXEC_BACKEND?)
I was under the impression thats where Itagaki-san develops.You'll
note some ot
On Thu, Jan 1, 2009 at 3:55 PM, Tom Lane wrote:
> "Robert Haas" writes:
>> Am I correct in thinking that the only thing we're really checking for
>> here is whether a trivial posix_fadvise() call returns success? If
>> so, is this test really worth doing?
>
> Runtime tests performed during confi
"Alex Hunsaker" writes:
> ... So Im going to mark it as
> ready for commmiter.
Has this patch been tested on Windows? (Or more generally, with EXEC_BACKEND?)
The reason I ask is that eyeballing the code suggests a couple of major
problems in that area:
* the startup/shutdown hooks will be ins
Bruce Momjian wrote:
Andrew Chernow wrote:
I am not a lawyer, but if its one work, why is there a notice in every source
file? ISTM that if it were one work there would only have to be one notice.
Because people often take source files and copy them for use in other
projects.
As
Andrew Chernow wrote:
Bruce Momjian wrote:
Greg Stark wrote:
Is that actually legal if we haven't modified the files? Or is the
whole source tree considiered one work?
One work, I assume.
I am not a lawyer, but if its one work, why is there a notice in every
source file? ISTM that if it wer
Hannu Krosing writes:
> On Mon, 2008-11-03 at 19:07 -0500, Tom Lane wrote:
>> The status of this patch isn't clear --- are you still working on it?
>> There certainly appear to be a lot of debug leftovers that need to
>> be removed, error messages to clean up, etc.
> It passes all existing regres
Peter Eisentraut wrote:
> Well, what this function essentially does is a text transformation of the
> options, something like this:
>
> peter=# SELECT array_to_string(fdwoptions || srvoptions || umoptions, ' ')
> FROM pg_foreign_data_wrapper fdw, pg_foreign_server srv, pg_user_mappings um
> WHE
"Robert Haas" writes:
> Am I correct in thinking that the only thing we're really checking for
> here is whether a trivial posix_fadvise() call returns success? If
> so, is this test really worth doing?
Runtime tests performed during configure are generally a bad idea to
start with --- it's impo
I tried this on my laptop running FC9, and because I forgot to run
autoconf, I got this error message when I tried to turn on
posix_fadvise.
rhaas=# set effective_io_concurrency to 3;
ERROR: could not determine if this system has a working posix_fadvise
DETAIL: Check configure.log produced by co
Joshua D. Drake wrote:
> On Thu, 2009-01-01 at 14:47 -0500, Bruce Momjian wrote:
> > Andrew Chernow wrote:
> > > Bruce Momjian wrote:
> > > > Greg Stark wrote:
> > > >> Is that actually legal if we haven't modified the files? Or is the
> > > >> whole source tree considiered one work?
> > > >
> >
Greg Stark writes:
> Is that actually legal if we haven't modified the files? Or is the
> whole source tree considiered one work?
[ shrug... ] We've always done it this way.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Thu, 2009-01-01 at 14:47 -0500, Bruce Momjian wrote:
> Andrew Chernow wrote:
> > Bruce Momjian wrote:
> > > Greg Stark wrote:
> > >> Is that actually legal if we haven't modified the files? Or is the
> > >> whole source tree considiered one work?
> > >
> > > One work, I assume.
> > >
> >
>
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Greg Stark wrote:
> >> Is that actually legal if we haven't modified the files? Or is the
> >> whole source tree considiered one work?
> >
> > One work, I assume.
> >
>
> I am not a lawyer, but if its one work, why is there a notice in every sou
Bruce Momjian wrote:
Greg Stark wrote:
Is that actually legal if we haven't modified the files? Or is the
whole source tree considiered one work?
One work, I assume.
I am not a lawyer, but if its one work, why is there a notice in every source
file? ISTM that if it were one work there wo
Greg Stark wrote:
> Is that actually legal if we haven't modified the files? Or is the
> whole source tree considiered one work?
One work, I assume.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard driv
Is that actually legal if we haven't modified the files? Or is the
whole source tree considiered one work?
--
Greg
On 1 Jan 2009, at 13:25, Bruce Momjian wrote:
I have updated all the source files for a 2009 copyright; seems the
commit message was suppressed due to its size. Tom found a
On Wed, 31 Dec 2008 13:08:20 -0500 Tom Lane wrote:
> "Andreas 'ads' Scherbaum" writes:
> > On Sun, 28 Dec 2008 18:19:48 -0500 Tom Lane wrote:
> >> If we're going to do this, shouldn't it happen uniformly for *all*
> >> ACL displays in describe.c?
>
> > Makes sense, imho.
>
> Done.
Oh, thanks.
Magnus Hagander writes:
> The kerberos configuration options (krb_caseinsens_users, krb_realm,
> krb_server_keyfile, krb_srvname, krb_server_hostname) are all set as
> PGC_POSTMASTER. From what I can see, the only places where kerberos code
> is called is from ClientAuthentication().
> That means
I have updated all the source files for a 2009 copyright; seems the
commit message was suppressed due to its size. Tom found a few more and
I have adjusted for those as well.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If
The kerberos configuration options (krb_caseinsens_users, krb_realm,
krb_server_keyfile, krb_srvname, krb_server_hostname) are all set as
PGC_POSTMASTER. From what I can see, the only places where kerberos code
is called is from ClientAuthentication().
That means these parameters shouldn't need to
On Thu, 2009-01-01 at 12:00 +0200, Heikki Linnakangas wrote:
> Greg Stark wrote:
> >
> > On 31 Dec 2008, at 13:21, Simon Riggs wrote:
> >>
> >> Both of these bugs are minor, but the effect of either/both of them is
> >> to cause more AccessExclusiveLocks than we might expect.
> >>
> >> For Hot S
On Wed, 2008-12-31 at 21:45 +0200, Heikki Linnakangas wrote:
> > Can I fix?
>
> Yes please.
Fix attached.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/commands/vacuumlazy.c
==
On Wed, 2008-12-31 at 14:45 -0500, Greg Stark wrote:
> On 31 Dec 2008, at 13:21, Simon Riggs wrote:
> >
> > Both of these bugs are minor, but the effect of either/both of them is
> > to cause more AccessExclusiveLocks than we might expect.
> >
> > For Hot Standby this means that many VACUUMs take
> I am not thrilled about inventing a new column for this, but how about
> a display like so:
>
> regression=# \df nth_value
>List of functions
> Schema | Name| Result data type | Argument data types
> +---+--+-
Hi,
Happy new year!
Le 31 déc. 08 à 17:04, Tom Lane a écrit :
However, it seems kind of inconsistent to do this for window functions
unless we also make \df start putting parens around the argument lists
for regular functions. Comments?
A way to distinguish between window functions "seeing"
Greg Stark wrote:
On 31 Dec 2008, at 13:21, Simon Riggs wrote:
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
on relations, which would pote
崔岩ccuiy...@sina.com wrote:
I want to get the number of misses for the buffer pool of PostgreSQL.
Is there any methods or
performance tools I can use to get the information?
Yes. Please see the manual chapters on "Monitoring database activity".
The pgstatio_* views in particular.
P
Dear all:
A quick question about shared buffers in PostgreSQL:
I want to get the number of misses for the buffer pool of PostgreSQL.
Is there any methods or
performance tools I can use to get the information?
Best Wishes
yyan
41 matches
Mail list logo
