Re: [PATCHES] [HACKERS] Including Snapshot Info with Indexes
Hi, I would like to present the first patch. It currently has the following restrictions a) It does not support any functional indexes. b) It supports queries like select count(1) from table where (restrictions from indexed columns), but it does not support select count(1) from table. The Syntax to create this type of index is create thick index idx on dd(n1,n2) here idx- index name and dd- table name and n1 and n2 are column names. I have created a extra column in pg_index called indhassnapshot. I have also enabled the display of Logical Reads. In order to see that, set log_statement_stats on. The thick index is clearly on the front, if you issue queries like select n2 from dd where n11000 and n21500; As already said, if the update is not incurring any extra cost, except if the indexed columns are updated. Deletes are costly, making it ideal for partitioned tables. In order to update the thick indexes, i have accessed the ps_ExprContext in PlanState to get the oldtuple. But if we have a outer plan and inner plan, then i have set the ps_ExprContext of innerplan to the outerplan. I don't know whether there will be instances where the ps_ExprContext of outerplan node will have some use in update queries. Right now, it passes the regression test suite. I had slight trouble with pg_indent, so i think it has not got applied properly. But i have tried to remove all the whitespace differences. Please be kind to me in case i have missed any whitespace differences. :) Please review the patch and provide your comments. Thanks, Gokul. CertoSQL Project, Allied Solution Groups. (www.alliedgroups.com) On 10/23/07, Hannu Krosing [EMAIL PROTECTED] wrote: Ühel kenal päeval, L, 2007-10-20 kell 10:19, kirjutas Luke Lonergan: Hi Hannu, On 10/14/07 12:58 AM, Hannu Krosing [EMAIL PROTECTED] wrote: What has happened in reality, is that the speed difference between CPU, RAM and disk speeds has _increased_ tremendously Yes. which makes it even more important to _decrease_ the size of stored data if you want good performance Or bring the cpu processing closer to the data it's using (or both). By default, the trend you mention first will continue in an unending way - the consequence is that the distance between a processor and it's target data will continue to increase ad-infinitum. the emergence of solid-state (flash) disks may help a little here, but in general it is true. By contrast, you can only decrease the data volume so much - so in the end you'll be left with the same problem - the data needs to be closer to the processing. This is the essence of parallel / shared nothing architecture. Note that we've done this at Greenplum. We're also implementing a DSM-like capability and are investigating a couple of different hybrid row / column store approaches. Have you tried moving the whole visibility part of tuples out to a separate heap ? Especially in OLAP/ETL scenarios the distribution of tuples loaded in one transaction should be very good for visibility-info compression. I'd suspect that you could crush hundreds of pages worth of visibility into single RLE encoding unit (xmin=N, xmax=no_yet, start_ctid = X, end_ctid=Y), and it will stay in L1 cache most of the time you process the corresponding relation. and the relation itself will be smaller, and index-only (actually index-only + lookup inside L1 cache) access can happen, and so on . OTOH, if you load it in millions of small transactions, you can run VACUUM FREEZE _on_ the visibility heap only, which will make all visibility infoe look similar and thus RLE-compressable and again make it fit in L1 cache, if you dont have lots of failed loads interleaved with successful ones. Bitmap index with index-only access does provide nearly all of the advantages of a column store from a speed standpoint BTW. Even though Vertica is touting speed advantages - our parallel engine plus bitmap index will crush them in benchmarks when they show up with real code. Meanwhile they're moving on to new ideas - I kid you not Horizontica is Dr. Stonebraker's new idea :-) Sounds like a result of a marketroid brainstorming session :P So - bottom line - some ideas from column store make sense, but it's not a cure-all. There is also a MonetDB/X100 project, which tries to make MonetOD order(s) of magnitude faster by doing in-page compression in order to get even more performance, see: Actually, the majority of the points made by the MonetDB team involve decreasing the abstractions in the processing path to improve the IPC (instructions per clock) efficiency of the executor. The X100 part was about doing in-page compression, so the efficiency of disk to L1 cache pathway would increase. so for 1/2 compression the CPU would get twice the data threoughput. We are also planning to do this by operating on data in vectors of projected rows in the
Re: [PATCHES] [HACKERS] Including Snapshot Info with Indexes
Gokulakannan Somasundaram wrote: I would like to present the first patch. It currently has the following restrictions a) It does not support any functional indexes. b) It supports queries like select count(1) from table where (restrictions from indexed columns), but it does not support select count(1) from table. An interesting question is how to represent tuples coming from the index in the executor. I see that you didn't address that at all, because you only support COUNT(1), and not things like SELECT column FROM table WHERE id = ? where you actually return datums from the index. But that's something that we have to think about in the DSM approach as well. One solution is to form a heap tuple, using the datums from the index, with the attributes that are not used in the query replaced with NULLs. That seems simple, but I don't think it'll work with expression indexes, when you do something like SELECT length(column) FROM table WHERE id = ?, and there's an index on (id, length(column)). I have also enabled the display of Logical Reads. In order to see that, set log_statement_stats on. You should start benchmarking, to verify that you're really getting the kind of speed up you're looking for, before you spend any more effort on that. Reduction in logical reads alone isn't enough. Remember that for a big change like that, the gain has to be big as well. As a first test, I'd like to see results from SELECTs on different sized tables. On tables that fit in cache, and on tables that don't. Tables large enough that the index doesn't fit in cache. And as a special case, on a table just the right size that a normal index fits in cache, but a thick one doesn't. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Including Snapshot Info with Indexes
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote: Gokulakannan Somasundaram wrote: I would like to present the first patch. It currently has the following restrictions a) It does not support any functional indexes. b) It supports queries like select count(1) from table where (restrictions from indexed columns), but it does not support select count(1) from table. An interesting question is how to represent tuples coming from the index in the executor. I see that you didn't address that at all, because you only support COUNT(1), and not things like SELECT column FROM table WHERE id = ? where you actually return datums from the index. But that's something that we have to think about in the DSM approach as well. That's addressed as well. One solution is to form a heap tuple, using the datums from the index, with the attributes that are not used in the query replaced with NULLs. That seems simple, but I don't think it'll work with expression indexes, when you do something like SELECT length(column) FROM table WHERE id = ?, and there's an index on (id, length(column)). I have also enabled the display of Logical Reads. In order to see that, set log_statement_stats on. You should start benchmarking, to verify that you're really getting the kind of speed up you're looking for, before you spend any more effort on that. Reduction in logical reads alone isn't enough. Remember that for a big change like that, the gain has to be big as well. As a first test, I'd like to see results from SELECTs on different sized tables. On tables that fit in cache, and on tables that don't. Tables large enough that the index doesn't fit in cache. And as a special case, on a table just the right size that a normal index fits in cache, but a thick one doesn't. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Re: [PATCHES] EXECUTE USING for plpgsql (for 8.4)
Pavel Stehule wrote:
Hello
this patch add USING clause into plpgsql EXECUTE statements.
Proposal:
http://archives.postgresql.org/pgsql-hackers/2007-10/msg00790.php
I found, so dynamics statements are little bit faster with parameters,
because we don't need call lot of in out/in functions. Mainly it is
barier to SQL injection.
FWIW, it looks pretty good to me.
This doesn't work:
create function exc_using(varchar) returns varchar
as $$
declare v varchar;
begin
execute 'select upper($1)' into v using ('aa');
return v;
end
$$ language plpgsql;
postgres=# SELECT exc_using('fooa');
ERROR: failed to find conversion function from unknown to text
CONTEXT: SQL statement select upper($1)
PL/pgSQL function exc_using line 3 at EXECUTE statement
I also noted that the patch makes USING a keyword. Not sure if we care
about that or not.
I have question, who will be commiter of plpgsql region? I am quite
irritated from 8.3 process. Bruce's patch queue more or less black
hole, and I have not any idea, if somebody checking my patches or not
and if I have to be in readiness or not.
Patch queue is longer and longer, and I need to know any responsible
person who can be recipient of my reminder request. Really it's
nothing nice, if your work is repeatedly deleted or inserted to
current queue. Nobody can do any plans.
All I can say is that I can feel your pain. Let's hope and do our best
to make 8.4 smoother.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] EXECUTE USING for plpgsql (for 8.4)
This doesn't work:
create function exc_using(varchar) returns varchar
as $$
declare v varchar;
begin
execute 'select upper($1)' into v using ('aa');
it cannot work. Your parameter is row. But
into v using 'aaa' doesn't work too :(
ERROR: failed to find conversion function from unknown to text
CONTEXT: SQL statement select upper($1)
you have to specify type: use argument, variable or casting
using text 'aaa'; or select upper($1::text)
It is question for Tom. Why prepared statement cannot cast from literal to text
http://www.nabble.com/Blowback-from-text-conversion-changes-t3977711.html
I also noted that the patch makes USING a keyword. Not sure if we care
about that or not.
I am afraid to change well know syntax (SQL/PSM use it in same context too).
Pavel
---(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] Win32: Minimising desktop heap usage
Dave Page [EMAIL PROTECTED] writes: [ get rid of wsprintf in favor of snprintf ] +1 for not depending on nonstandard subroutines without need. But please note the standard locution is snprintf(buf, sizeof(buf), ... Not sizeof() - 1. ! char*tmppath=0; Please use NULL not 0 ... actually, since the variable is unconditionally assigned to just below, I'd say this should just be char *tmppath;. I don't like useless initializations: if the compiler is not smart enough to discard them then they waste cycles, and they also increase the risk of bugs-of-omission in future changes. If someone were to change things around so that tmppath didn't get assigned to in one code path, then the compiler would complain about use of an uninitialized variable --- *unless* you've written a useless initialization such as the above, in which case the mistake might pass unnoticed for awhile. So don't initialize a local variable unless you're giving it an actually meaningful value. ! /* ! * Note: We use getenv here because the more modern SHGetSpecialFolderPath() ! * will force us to link with shell32.lib which eats valuable desktop heap. ! */ ! tmppath = getenv(APPDATA); Hmm, is there any functional downside to this? I suppose SHGetSpecialFolderPath does some things that getenv does not... Otherwise it looks good... regards, tom lane ---(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] Win32: Minimising desktop heap usage
Dave Page [EMAIL PROTECTED] writes: Tom Lane wrote: So don't initialize a local variable unless you're giving it an actually meaningful value. The downside is that we see a useless warning that, if sufficiently multiplied, might make it hard to see something we are interested in. [ looks again... ] Actually, I think you just proved my point for me. The ZeroMemory call should go away, no? (Does this mean that the Windows builds fail to detect dereferencing NULL? Bad if so.) Hmm, is there any functional downside to this? I suppose SHGetSpecialFolderPath does some things that getenv does not... A good percentage of the special folder paths you might query with SHGetSpecialFolderPath() are not actually in the environment. APPDATA certainly is on XP, 2K3 and Vista though, and I've found MS KB articles referring to it being on 2K as well. OK, in that case seems no problem. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Win32: Minimising desktop heap usage
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
[ get rid of wsprintf in favor of snprintf ]
+1 for not depending on nonstandard subroutines without need.
But please note the standard locution is snprintf(buf, sizeof(buf), ...
Not sizeof() - 1.
Noted.
!char*tmppath=0;
Please use NULL not 0 ... actually, since the variable is
unconditionally assigned to just below, I'd say this should just be
char *tmppath;. I don't like useless initializations: if the compiler
is not smart enough to discard them then they waste cycles, and they
also increase the risk of bugs-of-omission in future changes. If
someone were to change things around so that tmppath didn't get assigned
to in one code path, then the compiler would complain about use of an
uninitialized variable --- *unless* you've written a useless
initialization such as the above, in which case the mistake might pass
unnoticed for awhile. So don't initialize a local variable unless
you're giving it an actually meaningful value.
The downside is that we see a useless warning that, if sufficiently
multiplied, might make it hard to see something we are interested in.
In this case, not initialising it will also create the first 'accepted'
warning in VC++ in our code :-(. All the others come from Kerberos.
Modified in the attached patch however.
! /*
! * Note: We use getenv here because the more modern
SHGetSpecialFolderPath()
! * will force us to link with shell32.lib which eats valuable desktop
heap.
! */
! tmppath = getenv(APPDATA);
Hmm, is there any functional downside to this? I suppose
SHGetSpecialFolderPath does some things that getenv does not...
A good percentage of the special folder paths you might query with
SHGetSpecialFolderPath() are not actually in the environment. APPDATA
certainly is on XP, 2K3 and Vista though, and I've found MS KB articles
referring to it being on 2K as well.
Regards, Dave.
Index: src/backend/port/win32/signal.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/port/win32/signal.c,v
retrieving revision 1.18
diff -c -r1.18 signal.c
*** src/backend/port/win32/signal.c 5 Jan 2007 22:19:35 - 1.18
--- src/backend/port/win32/signal.c 23 Oct 2007 14:44:35 -
***
*** 178,184
char pipename[128];
HANDLE pipe;
! wsprintf(pipename, .\\pipe\\pgsignal_%d, (int) pid);
pipe = CreateNamedPipe(pipename, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
--- 178,184
char pipename[128];
HANDLE pipe;
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, (int) pid);
pipe = CreateNamedPipe(pipename, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
***
*** 251,257
char pipename[128];
HANDLE pipe = pgwin32_initial_signal_pipe;
! wsprintf(pipename, .\\pipe\\pgsignal_%d, GetCurrentProcessId());
for (;;)
{
--- 251,257
char pipename[128];
HANDLE pipe = pgwin32_initial_signal_pipe;
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, GetCurrentProcessId());
for (;;)
{
Index: src/port/kill.c
===
RCS file: /projects/cvsroot/pgsql/src/port/kill.c,v
retrieving revision 1.8
diff -c -r1.8 kill.c
*** src/port/kill.c 5 Jan 2007 22:20:02 - 1.8
--- src/port/kill.c 23 Oct 2007 14:44:35 -
***
*** 38,44
errno = EINVAL;
return -1;
}
! wsprintf(pipename, .\\pipe\\pgsignal_%i, pid);
if (!CallNamedPipe(pipename, sigData, 1, sigRet, 1, bytes, 1000))
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
--- 38,44
errno = EINVAL;
return -1;
}
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, pid);
if (!CallNamedPipe(pipename, sigData, 1, sigRet, 1, bytes, 1000))
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
Index: src/port/path.c
===
RCS file: /projects/cvsroot/pgsql/src/port/path.c,v
retrieving revision 1.71
diff -c -r1.71 path.c
*** src/port/path.c 5 Jan 2007 22:20:02 - 1.71
--- src/port/path.c 23 Oct 2007 14:47:29 -
***
*** 628,637
strlcpy(ret_path, pwd-pw_dir, MAXPGPATH);
return true;
#else
! char tmppath[MAX_PATH];
ZeroMemory(tmppath, sizeof(tmppath));
! if (SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, tmppath) != S_OK)
return false;
snprintf(ret_path, MAXPGPATH, %s/postgresql, tmppath);
return true;
--- 628,643
strlcpy(ret_path, pwd-pw_dir, MAXPGPATH);
return true;
#else
! char *tmppath;
ZeroMemory(tmppath, sizeof(tmppath));
!
! /*
! * Note: We use getenv here because the more modern SHGetSpecialFolderPath()
! * will force us to link with shell32.lib which eats valuable desktop heap.
! */
!
Re: [PATCHES] Win32: Minimising desktop heap usage
Tom Lane [EMAIL PROTECTED] writes: ! /* ! * Note: We use getenv here because the more modern SHGetSpecialFolderPath() ! * will force us to link with shell32.lib which eats valuable desktop heap. ! */ ! tmppath = getenv(APPDATA); Hmm, is there any functional downside to this? I suppose SHGetSpecialFolderPath does some things that getenv does not... The functional difference appears to be that the environment variable is set on startup (or login?) and doesn't necessarily have the most up to date value if it's been changed. But it's not something you're likely to change and you can always adjust the environment variable manually to fix the problem. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Win32: Minimising desktop heap usage
Tom Lane wrote:
[ looks again... ] Actually, I think you just proved my point for me.
The ZeroMemory call should go away, no?
Yup, quite correct. v3 attached.
/D
Index: src/backend/port/win32/signal.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/port/win32/signal.c,v
retrieving revision 1.18
diff -c -r1.18 signal.c
*** src/backend/port/win32/signal.c 5 Jan 2007 22:19:35 - 1.18
--- src/backend/port/win32/signal.c 23 Oct 2007 16:02:41 -
***
*** 178,184
char pipename[128];
HANDLE pipe;
! wsprintf(pipename, .\\pipe\\pgsignal_%d, (int) pid);
pipe = CreateNamedPipe(pipename, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
--- 178,184
char pipename[128];
HANDLE pipe;
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, (int) pid);
pipe = CreateNamedPipe(pipename, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
***
*** 251,257
char pipename[128];
HANDLE pipe = pgwin32_initial_signal_pipe;
! wsprintf(pipename, .\\pipe\\pgsignal_%d, GetCurrentProcessId());
for (;;)
{
--- 251,257
char pipename[128];
HANDLE pipe = pgwin32_initial_signal_pipe;
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, GetCurrentProcessId());
for (;;)
{
Index: src/port/kill.c
===
RCS file: /projects/cvsroot/pgsql/src/port/kill.c,v
retrieving revision 1.8
diff -c -r1.8 kill.c
*** src/port/kill.c 5 Jan 2007 22:20:02 - 1.8
--- src/port/kill.c 23 Oct 2007 16:02:41 -
***
*** 38,44
errno = EINVAL;
return -1;
}
! wsprintf(pipename, .\\pipe\\pgsignal_%i, pid);
if (!CallNamedPipe(pipename, sigData, 1, sigRet, 1, bytes, 1000))
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
--- 38,44
errno = EINVAL;
return -1;
}
! snprintf(pipename, sizeof(pipename), .\\pipe\\pgsignal_%u, pid);
if (!CallNamedPipe(pipename, sigData, 1, sigRet, 1, bytes, 1000))
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
Index: src/port/path.c
===
RCS file: /projects/cvsroot/pgsql/src/port/path.c,v
retrieving revision 1.71
diff -c -r1.71 path.c
*** src/port/path.c 5 Jan 2007 22:20:02 - 1.71
--- src/port/path.c 23 Oct 2007 16:04:42 -
***
*** 628,637
strlcpy(ret_path, pwd-pw_dir, MAXPGPATH);
return true;
#else
! char tmppath[MAX_PATH];
! ZeroMemory(tmppath, sizeof(tmppath));
! if (SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, tmppath) != S_OK)
return false;
snprintf(ret_path, MAXPGPATH, %s/postgresql, tmppath);
return true;
--- 628,641
strlcpy(ret_path, pwd-pw_dir, MAXPGPATH);
return true;
#else
! char *tmppath;
! /*
! * Note: We use getenv here because the more modern SHGetSpecialFolderPath()
! * will force us to link with shell32.lib which eats valuable desktop heap.
! */
! tmppath = getenv(APPDATA);
! if (!tmppath)
return false;
snprintf(ret_path, MAXPGPATH, %s/postgresql, tmppath);
return true;
---(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] Win32: Minimising desktop heap usage
Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: ! /* ! * Note: We use getenv here because the more modern SHGetSpecialFolderPath() ! * will force us to link with shell32.lib which eats valuable desktop heap. ! */ ! tmppath = getenv(APPDATA); Hmm, is there any functional downside to this? I suppose SHGetSpecialFolderPath does some things that getenv does not... The functional difference appears to be that the environment variable is set on startup (or login?) and doesn't necessarily have the most up to date value if it's been changed. But it's not something you're likely to change and you can always adjust the environment variable manually to fix the problem. If you're hacking the registry to change it then you've only got yourself to blame if you don't update the environment as well imho. I also wouldn't be at all surprised if many apps build paths containing the value returned by SHGetSpecialFolderPath() (or %APPDATA%) at startup and then use that value from then on rather than repeatedly calling the API function. It's not like you'd expect the value to change at all often, if ever. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] uuid.h on Debian
Compiling contrib/uuid-ossp on my Debian laptop failed, because apparently on Debian the uuid.h header is installed as ossp/uuid.h. That's probably to avoid confusion with other UUID implementations; there's at least one included with e2fsprogs, but fortunately the header file for that is called uuid/uuid.h. Attached is a patch that adds some autoconf magic to deal with that. I'm testing ossp/uuid.h first, because presumably if that exists it's the right one, while I suspect there might be other files called just uuid.h on other systems that are not the same thing. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: configure.in === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/configure.in,v retrieving revision 1.529 diff -c -r1.529 configure.in *** configure.in 5 Oct 2007 02:55:41 - 1.529 --- configure.in 23 Oct 2007 16:09:21 - *** *** 899,904 --- 899,911 AC_CHECK_HEADER(DNSServiceDiscovery/DNSServiceDiscovery.h, [], [AC_MSG_ERROR([header file DNSServiceDiscovery/DNSServiceDiscovery.h is required for Bonjour])]) fi + # for contrib/uuid-ossp + if test $with_ossp_uuid = yes ; then + AC_CHECK_HEADERS(ossp/uuid.h, [], [ + AC_CHECK_HEADERS(uuid.h, [], + [AC_MSG_ERROR([header file ossp/uuid.h or uuid.h is required for OSSP-UUID])])]) + fi + ## ## Types, structures, compiler characteristics Index: contrib/uuid-ossp/uuid-ossp.c === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/contrib/uuid-ossp/uuid-ossp.c,v retrieving revision 1.2 diff -c -r1.2 uuid-ossp.c *** contrib/uuid-ossp/uuid-ossp.c 15 May 2007 19:47:51 - 1.2 --- contrib/uuid-ossp/uuid-ossp.c 23 Oct 2007 16:20:09 - *** *** 14,21 #include utils/builtins.h #include utils/uuid.h ! #include uuid.h ! /* better both be 16 */ #if (UUID_LEN != UUID_LEN_BIN) --- 14,35 #include utils/builtins.h #include utils/uuid.h ! /* ! * There's some confusion over the location of the uuid.h header file. ! * On Debian, it's installed as ossp/uuid.h, while on Fedora, or if you ! * install ossp-uuid from a tarball, it's installed as uuid.h. Don't know ! * what other systems do. ! */ ! ! #ifdef HAVE_OSSP_UUID_H ! # include ossp/uuid.h ! #else ! # ifdef HAVE_UUID_H ! # include uuid.h ! # else ! # error OSSP uuid.h not found ! # endif ! #endif /* better both be 16 */ #if (UUID_LEN != UUID_LEN_BIN) Index: src/include/pg_config.h.in === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/include/pg_config.h.in,v retrieving revision 1.123 diff -c -r1.123 pg_config.h.in *** src/include/pg_config.h.in 2 Oct 2007 00:25:20 - 1.123 --- src/include/pg_config.h.in 23 Oct 2007 16:16:59 - *** *** 302,307 --- 302,310 /* Define to 1 if you have the `on_exit' function. */ #undef HAVE_ON_EXIT + /* Define to 1 if you have the ossp/uuid.h header file. */ + #undef HAVE_OSSP_UUID_H + /* Define to 1 if you have the pam/pam_appl.h header file. */ #undef HAVE_PAM_PAM_APPL_H *** *** 562,567 --- 565,573 /* Define to 1 if you have the utime.h header file. */ #undef HAVE_UTIME_H + /* Define to 1 if you have the uuid.h header file. */ + #undef HAVE_UUID_H + /* Define to 1 if you have the `vsnprintf' function. */ #undef HAVE_VSNPRINTF ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Win32: Minimising desktop heap usage
Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: Tom Lane wrote: So don't initialize a local variable unless you're giving it an actually meaningful value. The downside is that we see a useless warning that, if sufficiently multiplied, might make it hard to see something we are interested in. [ looks again... ] Actually, I think you just proved my point for me. The ZeroMemory call should go away, no? (Does this mean that the Windows builds fail to detect dereferencing NULL? Bad if so.) Windows builds don't fail to detect that in genereal. ZeroMemory, however, has a protection specifically against being passed NULL input, IIRC. //Magnus ---(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] Win32: Minimising desktop heap usage
Dave Page wrote: Tom Lane wrote: [ looks again... ] Actually, I think you just proved my point for me. The ZeroMemory call should go away, no? Yup, quite correct. v3 attached. Great job tracking this down! Patch looks good from here (after the fixes per Tom). Applied, many thanks! //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] EXECUTE USING for plpgsql (for 8.4)
Pavel Stehule wrote:
This doesn't work:
create function exc_using(varchar) returns varchar
as $$
declare v varchar;
begin
execute 'select upper($1)' into v using ('aa');
it cannot work. Your parameter is row.
Really? execute 'select upper($1)' into v using ('aa'::varchar);
works, as does execute 'select $1 + 1' into v using (12345);.
But into v using 'aaa' doesn't work too :(
ERROR: failed to find conversion function from unknown to text
CONTEXT: SQL statement select upper($1)
you have to specify type: use argument, variable or casting
using text 'aaa'; or select upper($1::text)
It is question for Tom. Why prepared statement cannot cast from literal to
text
http://www.nabble.com/Blowback-from-text-conversion-changes-t3977711.html
Yeah, I suppose we'll just live with that. Using literals as arguments
is kind of pointless anyway, since you could as well put the literal in
the query as well and not bother with the USING.
I also noted that the patch makes USING a keyword. Not sure if we care
about that or not.
I am afraid to change well know syntax (SQL/PSM use it in same context too).
No I think the syntax is fine. I'm just wondering if it really has to be
a reserved keyword to implement that syntax. Looking at the plpgsql
grammar close, we don't categorize keywords like we do in the main
grammar, so maybe what I'm saying doesn't make any sense.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] uuid.h on Debian
Heikki Linnakangas [EMAIL PROTECTED] writes: Compiling contrib/uuid-ossp on my Debian laptop failed, because apparently on Debian the uuid.h header is installed as ossp/uuid.h. Attached is a patch that adds some autoconf magic to deal with that. Applied, thanks. BTW, src/include/pg_config.h.in is a derived file (cf. autoheader); so there's no need to include it in a patch, any more than the configure script. It's probably a good idea to remind the committer to run autoheader, though. regards, tom lane ---(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] EXECUTE USING for plpgsql (for 8.4)
2007/10/23, Heikki Linnakangas [EMAIL PROTECTED]:
Pavel Stehule wrote:
This doesn't work:
create function exc_using(varchar) returns varchar
as $$
declare v varchar;
begin
execute 'select upper($1)' into v using ('aa');
it cannot work. Your parameter is row.
Really? execute 'select upper($1)' into v using ('aa'::varchar);
works, as does execute 'select $1 + 1' into v using (12345);.
No, propably not. I am not sure, when Postgres grouping fields into
row. Problem is only in unknown literal.
But into v using 'aaa' doesn't work too :(
ERROR: failed to find conversion function from unknown to text
CONTEXT: SQL statement select upper($1)
you have to specify type: use argument, variable or casting
using text 'aaa'; or select upper($1::text)
It is question for Tom. Why prepared statement cannot cast from literal to
text
http://www.nabble.com/Blowback-from-text-conversion-changes-t3977711.html
Yeah, I suppose we'll just live with that. Using literals as arguments
is kind of pointless anyway, since you could as well put the literal in
the query as well and not bother with the USING.
I also noted that the patch makes USING a keyword. Not sure if we care
about that or not.
I am afraid to change well know syntax (SQL/PSM use it in same context too).
No I think the syntax is fine. I'm just wondering if it really has to be
a reserved keyword to implement that syntax. Looking at the plpgsql
grammar close, we don't categorize keywords like we do in the main
grammar, so maybe what I'm saying doesn't make any sense.
yes, it's ok.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(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] vacuum as flags in PGPROC
Alvaro Herrera [EMAIL PROTECTED] writes: In the spirit of incremental improvement, here is a patch that turns the couple of bools in PGPROC into a bitmask, and associated fallout. Maybe declare the field as uint8 instead of char? Otherwise, +1. This patch also contains a change to make a cancelled autovacuum continue with the schedule (indeed to continue with the schedule on any error), rather than aborting completely. I think we'd considered that a bug to be fixed. Are you intending this for 8.3 or 8.4? I don't have a problem with it for 8.3, but someone else might ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
