On 12/16/2014 4:32 AM, Simon Riggs wrote:
On 15 December 2014 at 19:52, Josh Berkus wrote:
On 12/15/2014 11:27 AM, Robert Haas wrote:
I feel like we used to be better at encouraging people to participate
in the CF even if they were not experts, and to do the best they can
based on what they di
Purpose
Better test coverage of functions. On first call of a function, all sql
statements will be prepared, even those not directly called. Think:
create function test() returns void as $$
begin
if false then
select badcolumn from badtable;
end if;
end; $$ language plpgsql;
On 09/10/2011 02:52 PM, Peter Eisentraut wrote:
On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote:
I think the alphas have been extremely valuable for testing.
That's not my recollection. Obviously, it's hard to measure this one
way or the other, but I don't recall there being a lot of tes
On 09/10/2011 11:39 AM, Alexey Klyukin wrote:
Hi Andy,
On Sep 7, 2011, at 6:40 AM, Andy Colson wrote:
Hi Alexey, I was taking a quick look at this patch, and have a question for ya.
...
Where did the other warnings go? Its right though, line 570 is bad. It also
seems to have killed the
On 09/10/2011 11:43 AM, Thom Brown wrote:
On 10 September 2011 17:40, Andy Colson wrote:
I'm playing with 9.2devel, and I can fill my logs with:
WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
368986878169601 target timestamp 368986897680812 last errno 0
WARNING: p
I'm playing with 9.2devel, and I can fill my logs with:
WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
368986878169601 target timestamp 368986897680812 last errno 0
WARNING: pgstat waiting for 5011780 usec (495 loops), file timestamp
368986878169601 target timestamp 3689
Hi Alexey, I was taking a quick look at this patch, and have a question for ya.
I have a default config from initdb, there is a new setting at the end but its
commented out.
root@storm: /db/pg92
# /etc/rc.d/postgresql start
Starting PostgreSQL:
root@storm: /db/pg92
# more serverlog
LOG: datab
On 08/22/2011 01:22 AM, Pavan Deolasee wrote:
Hi All,
Here is a revised patch based on our earlier discussion. I implemented
Robert's idea of tracking the vacuum generation number in the line
pointer itself. For LP_DEAD line pointers, the lp_off/lp_len is unused
(and always set to 0 for heap tup
Hi Pavel,
I can get:
ERROR: permission denied to set parameter "plpgsql.prepare_plans"
with this script:
set plpgsql.prepare_plans to on_start;
create or replace function test1(a integer) returns integer as $$
begin
return a+1;
end;
$$ language plpgsql;
If test1() exists, then this script
On 09/05/2011 05:27 PM, Andy Colson wrote:
On 09/05/2011 05:04 PM, Andrew Dunstan wrote:
On 09/05/2011 05:03 PM, Andy Colson wrote:
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
On 09/05/2011 05:04 PM, Andrew Dunstan wrote:
On 09/05/2011 05:03 PM, Andy Colson wrote:
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Timing is on.
psql (9.2devel)
Type "help
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Timing is on.
psql (9.2devel)
Type "help" for help.
andy=# set plpgsql.prepare_plans to on_start;
ERROR: unrecognized configuration parame
Pavel, I have not taken on your patch for review, but I was reading the history
of it, and one question popped up:
If you are allocating a new cache, what if the array is really big, will 1st
cache + your cache get bigger than work_mem? (or are array op's not
constrained by work_mem? Sorry,
This patch:
https://commitfest.postgresql.org/action/patch_view?id=597
caches the cache because, I guess, the cache is slow.
Simon asked, "What is making the first cache so slow?". Pavel does not know,
nor how to fix it, and nobody else responded.
So my question is: is someone going to take
On 09/05/2011 12:17 PM, Andy Colson wrote:
Tomas, I cannot seem to see any of the patches you link here:
https://commitfest.postgresql.org/action/patch_view?id=628
Looks like you need to take the < > out of the messageid.
-Andy
This patch seems to solve the problem of going back in t
This patch:
https://commitfest.postgresql.org/action/patch_view?id=605
Seems to have been after thoughts, and back burner stuff, and forgotten about...
Has it already been commit?
http://archives.postgresql.org/pgsql-committers/2011-07/msg00206.php
Oh, wait, nevermind, it was revoked and rewo
Tomas, I cannot seem to see any of the patches you link here:
https://commitfest.postgresql.org/action/patch_view?id=628
Looks like you need to take the < > out of the messageid.
-Andy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On 07/29/2011 04:00 PM, Robert Haas wrote:
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(), which glibc implements like this:
long int
__random ()
{
int32_t retval;
__libc_lock_lock (lock);
(v
On 03/05/2011 08:54 AM, Robert Haas wrote:
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
um.. are _not_ WAL-logged?
Uh, yeah. It looks like I fixed that in the version I committed, but
introduced another
On 03/05/2011 08:54 AM, Robert Haas wrote:
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
um.. are _not_ WAL-logged?
Uh, yeah. It looks like I fixed that in the version I committed, but
introduced another
On 03/04/2011 10:22 PM, Robert Haas wrote:
On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote:
So it seems like the only thing that is an absolute must-do is write
some release notes.
Here's a rough attempt at filtering the post-alpha3 commit log down to
approximately the set of things worth
On 3/3/2011 6:49 AM, Michael Meskes wrote:
On Wed, Mar 02, 2011 at 01:33:35PM -0600, Andy Colson wrote:
I thought Kris was going to work on this, but saw no progress, and I
was bored the other day, so I started working on it.
Here is a parse.pl, with some major refactoring.
I named it with a
On 1/23/2011 5:11 AM, Michael Meskes wrote:
On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote:
I think these really need to be rewritten from scratch. They look
like they were written by someone who never heard of Perl 5 (it's
only about 16 years old).
You might remember that we h
On 01/23/2011 10:06 AM, Andrew Dunstan wrote:
On 01/23/2011 10:16 AM, Andy Colson wrote:
On 01/23/2011 08:29 AM, Andy Colson wrote:
On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:
On 23 January 2011 13:14, Andrew Dunstan wrote:
But there are quite a few perlheads around. ISTR Matt Trout
On 01/23/2011 08:29 AM, Andy Colson wrote:
On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:
On 23 January 2011 13:14, Andrew Dunstan wrote:
But there are quite a few perlheads around. ISTR Matt Trout was muttering
about these scripts on IRC recently.
Ok, so I've figured out what its pu
On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:
On 23 January 2011 13:14, Andrew Dunstan wrote:
But there are quite a few perlheads around. ISTR Matt Trout was muttering
about these scripts on IRC recently.
A quick cleanup of the check_rules.pl...
It's a starting point at least.
Oh!
On 01/16/2011 07:14 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
This is a review of "plperl encoding issues"
https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
The Patch:
==
Applies cl
I reviewed a couple patched, and I added my review to the commitfest page.
If I find a problem, its obvious I should mark the patch as "returned with
feedback".
But what if I'm happy with it? I'm not a hacker so cannot do C code review, should I
leave it alone? Mark it as "ready for committ
This is a review of:
https://commitfest.postgresql.org/action/patch_view?id=468
Purpose:
Equal and not-equal _may_ be quickly determined if their lengths are different.
This _may_ be a huge speed up if we dont have to detoat.
The Patch:
==
I was able to read and understand t
This is a review of "plperl encoding issues"
https://commitfest.postgresql.org/action/patch_view?id=452
Purpose:
Your database uses one encoding, and passes data to perl in the same encoding,
which perl is not prepared for (it assumes UTF-8). This patch makes sure data
is encoded i
I know its been discussed before, and one big problem is license and
patent problems.
Would this project be a problem:
http://oldhome.schmorp.de/marc/liblzf.html
-Andy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think we could live with it.
+1
In the small s
2nd) I can get the data to stick around after restart. Though not reliably. In
general:
create and fill a table, vacuum it (not sure if its important, I do it because
thats what I'd done in my pgbench testing where I noticed the data stuck
around), wait an hour (I usually left it for 12-24 h
On 11/30/2010 10:27 PM, Robert Haas wrote:
This appears as though you've somehow gotten a normal table connected
to an unlogged index. That certainly sounds like a bug, but there's
not enough details here to figure out what series of steps I should
perform to recreate the problem.
There is \h
I have played around a little more, and think I found a problem.
If given enough time, an unlogged table makes it to disk, and a restart wont
clear the data. If I insert a bunch of stuff, commit, and quickly restart PG,
it table is cleared. If I let it sit for a while, it stays.
Based on tha
I have done a bunch of benchmarking. It was not easy to find consistent
numbers, so I picked a job and ran the same thing over and over.
I'm running Slackware 13.1 on a desktop computer.
Linux storm 2.6.35.7-smp #1 SMP Sun Oct 10 21:43:07 CDT 2010 i686 AMD
Athlon(tm) 7850 Dual-Core Processor
I was able to apply and compile and run ok, creating unlogged tables
seems to work as well.
I patched up pgbench to optionally create unlogged tables, and ran it
both ways. I get ~80tps normally, and ~1,500tps with unlogged. (Thats
from memory, was playing with it last night at home)
I als
I am attempting to test this
https://commitfest.postgresql.org/action/patch_view?id=424
but I'm not sure which version of PG this should be applied to. (it would be
really neat, on here:
https://commitfest.postgresql.org/action/commitfest_view?id=8
if there was a note that said, this test this
Tom Lane wrote:
Mark Cave-Ayland writes:
Thanks for the patch. Fortunately enough I was able to find the dataset
from the original report above, and so I've tested your patch against
PostgreSQL 8.4. Unfortunately in the original test case, it doesn't seem
to give the same performance improvem
Josh Berkus wrote:
Andy,
6) To the -hackers: I write the records and then refind them in the
exact same order, would it be a better test to search for records in a
more random order? would it make a difference? Would searching for some
but not all make a difference?
Are you on OpenSolaris? C
Floris Bos / Maxnet wrote:
The following settings differ from the defaults:
--
shared_buffers=3500MB
maintenance_work_mem = 128MB
fsync = off
synchronous_commit = off
checkpoint_segments = 25
--
==
Table layout
==
--
Table "public.posts_index"
Column |
Josh Berkus wrote:
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-watt said, at idle,
Greg Smith wrote:
On Thu, 28 May 2009, Andy Colson wrote:
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may
not be out of the ord
Jignesh K. Shah wrote:
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It
Greg Smith wrote:
On Wed, 27 May 2009, andy wrote:
I have a Sun blade 1000 that's just collecting dust now days...It
weighs a ton.
Bah, I know I picked one of those up myself once, which means it's far
from being what I'd consider a heavy server as Sun hardware goes. Specs
say it's 70 poun
Jaime Casanova wrote:
On 1/21/08, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
It's on my (very long) TODO list to add benchmarking as an option on the
buildfarm. If you're interested in working on it then contact me offline and
we will work on how to move forward.
any move in this?
Not much
Robert Treat wrote:
On Saturday 09 February 2008 22:51, Christopher Browne wrote:
On Feb 9, 2008 4:58 PM, Jan Wieck <[EMAIL PROTECTED]> wrote:
I wonder if the efforts to provide mirrors for many different systems can
hurt later down the road. It is pretty obvious that amost every current
system
Hi All,
You knew it was coming
I have an 8.2 database that has full text searching. I tried to
backup/restore it to 8.3 but got lots of errors:
ERROR: could not access file "$libdir/tsearch2": No such file or directory
ERROR: function public.gtsq_in(cstring) does not exist
ERROR: cou
48 matches
Mail list logo
