[PATCHES] Space management for PGresult
In space management for PGresult of libpq, the block size of PGresult is always PGRESULT_DATA_BLOCKSIZE(2048bytes). Therefore, when a large result of query is received, malloc is executed many times. My proposal is to enlarge the size of the block whenever the block is allocated. The size of first block is PGRESULT_DATA_BLOCKSIZE. And the size of the following blocks will be doubled until it reaches PGRESULT_MAX_DATA_BLOCKSIZE. PGRESULT_MAX_DATA_BLOCKSIZE is new constants. I think that 2Mbytes is good enough for this constants. The test result is the following: Test SQL: select * from accounts; (It is pgbench's table. scale factor is 10.) The number of malloc calls at pqResultAlloc: 8.1.0 : 80542 patched:86 Execution time: 8.1.0 : 6.80 sec patched: 6.73 sec regards, --- Atsushi Ogawa libpq_alloc.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] TODO Item - Add system view to show free space map
Bruce Momjian wrote: Mark Kirkwood wrote: Simon Riggs wrote: I like this, but not because I want to read it myself, but because I want to make autovacuum responsible for re-allocating free space when it runs out. This way we can have an autoFSM feature in 8.2 Not wanting to denigrate value of the interesting but slightly OT direction this thread has taken - but does anybody want to comment/review the patch itself :-) ? I saw this question about a transaction block and your reply: http://archives.postgresql.org/pgsql-patches/2005-10/msg00226.php but no new patch. I know someone suggested pgfoundry but it seems most natural in /contrib. Do you want to update the patch? In the expectation of further revisions, I was going to batch that one in with the 'rest' - given that there have not been any, I'll submit a revised patch. Cheers Mark ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Patch to allow contrib/pgbench files to have blank lines
Folks,
Having blank lines in -f scripts was causing silent failures. This
fixes it, for some value of "fixes." If it's OK, please apply to 8.1
CURRENT and CVS TIP :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
Index: contrib/pgbench/pgbench.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.46
diff -c -r1.46 pgbench.c
*** contrib/pgbench/pgbench.c 22 Nov 2005 18:17:04 - 1.46
--- contrib/pgbench/pgbench.c 23 Nov 2005 02:41:42 -
***
*** 886,896
{
Command*commands;
! commands = process_commands(buf);
! if (commands == NULL)
! {
! fclose(fd);
! return false;
}
my_commands[lineno] = commands;
--- 886,902
{
Command*commands;
!
! if (strncmp(buf, "\n", 1) != 0) {
! commands = process_commands(buf);
! if (commands == NULL)
! {
! fclose(fd);
! return false;
! }
! } else {
! lineno++;
! continue;
}
my_commands[lineno] = commands;
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] TODO Item - Add system view to show free space map
Mark Kirkwood wrote: > Simon Riggs wrote: > > > > > > I like this, but not because I want to read it myself, but because I > > want to make autovacuum responsible for re-allocating free space when it > > runs out. This way we can have an autoFSM feature in 8.2 > > > > > > Not wanting to denigrate value of the interesting but slightly OT > direction this thread has taken - but does anybody want to > comment/review the patch itself :-) ? I saw this question about a transaction block and your reply: http://archives.postgresql.org/pgsql-patches/2005-10/msg00226.php but no new patch. I know someone suggested pgfoundry but it seems most natural in /contrib. Do you want to update the patch? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
On Mon, Nov 21, 2005 at 07:50:48PM -0500, Andrew Dunstan wrote: > > Nice analysis, but we can't hack configure like that. It has to be able > to be fully generated from its sources. I think the other source file > you would need to look at is config/programs.m4. (Not sure about quoting > $ac_popdir - why only that one?) > > Also, I suspect we'd want to enable the libedit preference with a switch > rather than just force it, if we want to go this way. BTW, we've run into issues with readline from a licensing standpoint. It would be really nice if libedit was supported where practical (I suspect most mainstream OSes support libedit) since it's BSD licensed. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
On Tue, Nov 22, 2005 at 10:07:15AM +0100, Zeugswetter Andreas DCP SD wrote: > PS: I'd prefer if readline was only linked where it is needed, namely in > psql. The problem as stated is that people don't want to maintain lists of libraries as needed by each program, so we link all of them. Since it seems to always be the same few libraries that cause us problems, maybe a simpler approach would be to, in the Makefile, use filter-out to exclude libraries you *know* aren't needed. Like in the Makefile we put: postgres: $(OBJS) $(CC) $(CFLAGS) $(LDFLAGS) $(export_dynamic) $^ $(filter-out -lreadline -ledit, $(LIBS)) -o $@ So instead of maintaining lists of what each binary needs, we can maintain a few lists of what certain binaries *don't* need. Actually, I think the backend is the only thing important enough to worry about this, although if readline is exporting memcpy that it's quite possible other binaries might be affected. Maybe create a BACKEND_LIBS which contains a shorter list. Even the GCC --as-needed flag can't save you from libs exporting functions they shouldn't... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpxJaPHG2bqX.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
> With AIX 5, the easiest way to get a shared object is to pass "-bexpall" > to the linker. This results in all symbols being exported. Yes, that is another reason not to use this broken switch. And last time I checked (AIX 4.3.3), -bexpall did not export all needed symbols (e.g. globals) from the backend eighter. And the counterpart -bimpall did also not work. Dynamic loading did not work without the .imp and .exp files :-( Andreas PS: I'd prefer if readline was only linked where it is needed, namely in psql. ---(end of broadcast)--- TIP 6: explain analyze is your friend
