Re: [HACKERS] [JDBC] Where are we on stored procedures?
Hi, Francisco, Francisco Figueiredo Jr. schrieb: In fact, I think people keep requesting me support on Npgsql for that because MS Sql server supports it and they are porting their code to use Postgresql and facing that difficult. Indeed, for (a) we could use an approach similar to Ms sql server. We could have a way of the procedure say if it wanted to send the rows affected information or not. And about (b) I think that it is only on trivial cases that people really want to use this feature :) As you need to tweak the function/procedure source to implement (a), you can also tweak the function/procedure to return the row cound and whatever other diagnostics you need. For newly implemented stored procedures, we could create a special diagnostics result set that every procedure creates. This usually contains some success/error information, but the procedure could add additional rows to it. Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:[EMAIL PROTECTED] | www.logi-track.com signature.asc Description: OpenPGP digital signature
Re: [JDBC] [HACKERS] Where are we on stored procedures?
Hi, Tom, Tom Lane schrieb: Yeah, but only because you have to do it explicitly. I was wondering whether we couldn't bury that mechanism under the hood. (In particular, given the improved support in 8.0 for anonymous record types, we could in theory have the backend invent a record type on-the-fly to match whatever list of OUT parameters a particular function has.) It would not be necessarily on the fly, at least in the first step we possibly get away with declaraing the returned tuples at creation time and implicitly creating those tuple types. The declaration could be like returns (touchedrows int, somethingelse datetime), setof (article int, description text) for a function/method that has two resultsets, one of those with always one row. markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:[EMAIL PROTECTED] | www.logi-track.com signature.asc Description: OpenPGP digital signature
Re: [HACKERS] [NOVICE] Question on TRUNCATE privleges
On Thu, 24 Feb 2005 17:15:42 -0500, Tom Lane wrote Bruce Momjian pgman@candle.pha.pa.us writes: Uh, that seems like it adds extra complexity just for this single case. Yeah. I've dropped the idea personally -- the suggestion that the table owner can provide a SECURITY DEFINER procedure to do the TRUNCATE if he wants to allow others to do it seems to me to cover the problem. Could someone point me in the direction of documentation on this SECURITY DEFINER feature? Kind Regards, Keith ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Problems With PGAdmin
Hello everybody, I'm having a problem with pgadmin II and III. When I try to access a database it crash may system and I have to close it. I talk to my friends and they have the same problem when they try to acces this database. We can access this by a php page or asp but we can't do it by the pgAdmin. A frind of mine had a windows program (DBtools Manager Professional) that can work without any problem, but it doesn't work under linux (even with wine). How can I fix it? or is there another soft for linux that can access a pg database? -- Regards, Thiago Luiz [EMAIL PROTECTED] http://www.agsistemas.com.br ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] [Mail Delivery System Mailer-Daemon@xeocode.com] Mail delivery failed: returning message to sender
Incidentally, Tom, you seem to be using a pretty bogus blackhole list that includes blocking static address assignments based on the DNS records. I doubt this achieves much in the way of spam filtering, but it's preventing you from getting my mails. (Perhaps that's a good thing) ---BeginMessage--- This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after MAIL FROM:[EMAIL PROTECTED]: host sss.pgh.pa.us [66.207.139.130]: 550 5.7.1 Probable spam from 216.58.44.227 refused - see http://www.five-ten-sg.com/blackhole.php?216.58.44.227 -- This is a copy of the message, including all the headers. -- Return-path: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1D4Nor-0007wA-00; Thu, 24 Feb 2005 13:34:37 -0500 Sender: [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] Cc: Greg Stark [EMAIL PROTECTED], pgsql-hackers@postgresql.org Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] From: Greg Stark [EMAIL PROTECTED] Organization: The Emacs Conspiracy; member since 1992 Date: 24 Feb 2005 13:34:36 -0500 Message-ID: [EMAIL PROTECTED] Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: I'm a bit surprised that the write-cache lead to a corrupt database, and not merely lost transactions. I had the impression that drives still handled the writes in the order received. There'd be little point in having a cache if they did, I should think. I thought the point of the cache was to allow the disk to schedule I/O in an order that minimizes seek time (ie, such a disk has got its own elevator queue or similar). If that were the case then SCSI drives that ship with write caching disabled and using tagged command queuing instead would perform poorly. I think the main motivation for write caching on IDE drives is that the IDE protocol forces commands to be issued synchronously. So you can't send a second command until the first command has completed. Without write caching that limits the write bandwidth tremendously. Write caching is being used here as a poor man's tcq. -- greg ---End Message--- -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Finding if old transactions are running...
In an attempt to throw the authorities off his trail, Christopher Browne [EMAIL PROTECTED] transmitted: It sure would be nice to be able to have a way to query the start time of the eldest transaction on the system. I can see this function available in the backend: TransactionId GetOldestXmin(bool alldbs); The cost is based on walking thru each backend process, which I guess is obvious, as if there are 47 backends, that means 47 xids. Presumably not _too_ expensive; certainly something that has to be run every time a vacuum is requested. Is there a way to expose this? Without leaping into grand evil? -- output = (cbbrowne @ gmail.com) http://linuxdatabases.info/info/languages.html If you're not part of the solution, you're part of the precipitate. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] idea for concurrent seqscans
Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Assuming you're talkning about You might wonder why we don't order all the regression test queries explicitly to get rid of this issue once and for all. The reason is that that would make the regression tests less useful, not more, since they'd tend to exercise query plan types that produce ordered results to the exclusion of those that don't., good point. I can think of 2 ways around this: 1) Select into a temptable, then select out of it with an order by 2) Run the output through sort before doing the diff Is there any reason one of these wouldn't work? Like I said originally, we could certainly devise a solution if we needed to. I was just pointing out that this is a nontrivial consideration, and I don't want to buy into it if the patch proves to offer only marginal performance improvements. I'll bet will not offer only marginal performance improvements. I see some time my 4-CPU server with 3 CPU in holiday and other CPU working on a long sequential scan. I hope that this patch, if it works correctly will be used in future Postgresql version Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] serial as FK ?
On Mon, 28 Feb 2005, Richard Huxton wrote: Oleg Bartunov wrote: Hi there, what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ? qq=# create table t1( id serial); NOTICE: CREATE TABLE will create implicit sequence t1_id_seq for serial column t1.id CREATE TABLE qq=# create table t2( id2 int4 references t1(id)); ERROR: there is no unique constraint matching given keys for referenced table t1 btw, Richard, I noticed this problem when looked into your example database http://www.archonet.com/pgdocs/chap-exdb.html#EXAMPLE-TABLES Ah - IIRC there *was* nothing wrong with it when those notes were written (and I need to update them, clearly). Back then SERIAL implied UNIQUE too, but that was changed (in 7.3 I believe). There are also some problems in examples. I think your notes are rather useful. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] snprintf causes regression tests to fail
Nicolai Tufar wrote: Linux and Solaris 10 x86 pass regression tests fine when I force the use of new snprintf(). The problem should be win32 - specific. I will investigate it throughly tonight. Can someone experienced in win32 what can possibly be the problem? Yea, I am confused too because my BSD uses the new snprintf.c code was well. Magnus, what failures are you seeing on Win32? -- 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 3: 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: [HACKERS] Finding if old transactions are running...
I can see this function available in the backend: TransactionId GetOldestXmin(bool alldbs); The cost is based on walking thru each backend process, which I guess is obvious, as if there are 47 backends, that means 47 xids. Presumably not _too_ expensive; certainly something that has to be run every time a vacuum is requested. Is there a way to expose this? -- output = (cbbrowne @ gmail.com) http://linuxdatabases.info/info/languages.html If you're not part of the solution, you're part of the precipitate. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] snprintf causes regression tests to fail
Linux and Solaris 10 x86 pass regression tests fine when I force the use of new snprintf(). The problem should be win32 - specific. I will investigate it throughly tonight. Can someone experienced in win32 what can possibly be the problem? Nick On Sun, 27 Feb 2005 19:07:16 +0100, Magnus Hagander [EMAIL PROTECTED] wrote: Hi! The new snpritnf code appears not to deal with 64-bit ints. I'm getting failures on win32 for int8 as well as all the time related tests (win32 uses int8 for tinmestamps). Removing the snprintf code and falling back to the OS code makes everything pass again. I would guess this affects int8 etc on other platforms as well (assuming they use our snprintf and not the libc one), but I haven't checked it. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Problems With PGAdmin
Thiago Luiz wrote: Hello everybody, I'm having a problem with pgadmin II and III. When I try to access a database it crash may system and I have to close it. I talk to my friends and they have the same problem when they try to acces this database. We can access this by a php page or asp but we can't do it by the pgAdmin. A frind of mine had a windows program (DBtools Manager Professional) that can work without any problem, but it doesn't work under linux (even with wine). How can I fix it? or is there another soft for linux that can access a pg database? First of all, you should post requests like this on pgadmin-support. Second, you need to give much more information, which version/which os are you running, in which situations does it crash. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] serial as FK ?
Oleg Bartunov wrote: Hi there, what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ? qq=# create table t1( id serial); NOTICE: CREATE TABLE will create implicit sequence t1_id_seq for serial column t1.id CREATE TABLE qq=# create table t2( id2 int4 references t1(id)); ERROR: there is no unique constraint matching given keys for referenced table t1 btw, Richard, I noticed this problem when looked into your example database http://www.archonet.com/pgdocs/chap-exdb.html#EXAMPLE-TABLES Ah - IIRC there *was* nothing wrong with it when those notes were written (and I need to update them, clearly). Back then SERIAL implied UNIQUE too, but that was changed (in 7.3 I believe). -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] serial as FK ?
Hi there, what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ? qq=# create table t1( id serial); NOTICE: CREATE TABLE will create implicit sequence t1_id_seq for serial column t1.id CREATE TABLE qq=# create table t2( id2 int4 references t1(id)); ERROR: there is no unique constraint matching given keys for referenced table t1 btw, Richard, I noticed this problem when looked into your example database http://www.archonet.com/pgdocs/chap-exdb.html#EXAMPLE-TABLES Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SQL99 Hierarchical queries
Ok, I'm started porting it to 8.0.1 and will fix this also. By the way, did you know any test suit for such queries? To make some regression test. Regards, Evgen I tested you patch, and it's good work. I would all methods in PostgreSQL. I found query which kill backand WITH t AS ( SELECT 0::int AS i UNION ALL SELECT i + 1 FROM t WHERE i 100) SELECT * FROM t; Regards Pavel Stehule ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] snprintf causes regression tests to fail
Linux and Solaris 10 x86 pass regression tests fine when I force the use of new snprintf(). The problem should be win32 - specific. I will investigate it throughly tonight. Can someone experienced in win32 what can possibly be the problem? Do we have any idea about what format string causes the regression failure? It may be that certain integer types are not promoted uniformly when pushed on the stack. Nick On Sun, 27 Feb 2005 19:07:16 +0100, Magnus Hagander [EMAIL PROTECTED] wrote: Hi! The new snpritnf code appears not to deal with 64-bit ints. I'm getting failures on win32 for int8 as well as all the time related tests (win32 uses int8 for tinmestamps). Removing the snprintf code and falling back to the OS code makes everything pass again. I would guess this affects int8 etc on other platforms as well (assuming they use our snprintf and not the libc one), but I haven't checked it. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question
-Original Message- From: [EMAIL PROTECTED] on behalf of Bruce Momjian Sent: Sun 2/27/2005 12:54 AM To: Magnus Hagander Cc: Tom Lane; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]; Merlin Moncure Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question Patch applied. Thanks. I assume this is not approprate for 8.0.X. I think it would be good to backpatch it given proper testing - the changes are relatively minor, and they do give a significant performance boost. Regards, Dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Development Plans
Thanks to all replies on this thread over last few days, many good point and useful contributions, thank you. [Please excuse many non-replies, since I've been ill.] On Fri, 2005-02-25 at 09:41 -0800, Josh Berkus wrote: - What are you working towards? Performance? Stability? X? X, definitely X. Thats clear then. ;-) We're working toward PostgreSQL being indisputably the very best SQL RDBMS in the world. Hmmm, interestingly, that is not my objective. *Most-used* is both a sufficient and eventually realisable goal for me to contribute towards. Best seems like a niche, and not always a cost-effective one. I think I've come to understand the answers to many of these questions, but these answers are not written down. When I do answer them, I try to make it clear that I present a personal opinion only - but that always gets strange looks. People really do not understand why there is no official answer, and take that as a black mark. Well, they're used to dealing with private companies and company-sponsored projects. These things have marketing-driven agendas. We are a non-commercial, all-volunteer OSS project.You will need to educate people on this. WellI'm trying, thats why I wanted all of those things written down. Other projects such as Ubuntu, Fedora and OpenOffice have much of this type of information easily available OpenOffice.org and Fedora are both single-company-sponsored projects, with marketing-driven goals. I don't know about Ubuntu. OK, thats a good point. Ubuntu is single company too, and worse, it doesn't work on my laptop. - certainly commercial software vendors spend a good deal of time on providing this information. Yep. And commercial vendors ship releases whether or not that release is stable or actually contains the features advertised. Hmmm. Well, companies differ, lets say that. Could we find a way of expressing the project philosophy in writing, so I can convey that message out to the world, exactly as intended, without any Riggs filtering? That's not a small order, if we want to do it right.Why don't you prepare a Faq-ish page that covers these issues based on the responses you've received on this thread? I can add it to the Press FAQ. OK, well I was hoping that one-of-Core, not necessarily yourself, would be the one to put pen to paper on such an issue. ...but, I guess I'll have a stab at it. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] serial as FK ?
On Mon, 28 Feb 2005, Oleg Bartunov wrote: what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ? Serial isn't enough to guarantee uniqueness as required by foreign keys. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] SQL99 Hierarchical queries
On Mon, Feb 28, 2005 at 11:07:51AM +0300, Evgen Potemkin wrote: Ok, I'm started porting it to 8.0.1 and will fix this also. By the way, did you know any test suit for such queries? To make some regression test. Evgen, Thanks very much for doing this work. Is there some way you can summarize what you did so others can join you in working on it? If it is easier for you to write this in some language other than English, please do, and we'll find translators :) I noticed that the patch touches the parser, the optimizer and the executor. What does it to with each? What did I miss? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 3: 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: [HACKERS] snprintf causes regression tests to fail
After some extensive debugging with Magnus's
help we finally managed to a kind of isolate the
problem. We placed snprintf.c in a separate
file, added necessary #includes and wrote
a simple main() function:
main()
{
unsigned long long ull=4567890123456789ULL;
static char buf[1024];
mysnprintf(buf,1024,%lld\n,ull);
printf(buf);
}
When compiled with -D HAVE_LONG_LONG_INT_64=1
which declares long_long and ulong_long like:
typedef long long long_long;
typedef unsigned long long ulong_long;
It compiles fine and produces desired result. If not,
it produces -869367531 as in regression tests.
Amazingly enough HAVE_LONG_LONG_INT_64 is
defined when compilation comes to src/port/snprintf.c
but the result is still wrong. I looked into configure.in
but the check for HAVE_LONG_LONG_INT_64 is too
complicated for me to understand. Bruce, could you
take a look at this? I am 90% sure it is an issue with
some configure definitions.
Best regards,
Nicolai
On Mon, 28 Feb 2005 19:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
Regression test diff is attached.
It fails on the following tests:
int8
subselect
union
sequence
It fails to display correctly number 4567890123456789.
In output is shows -869367531. Apparent overflow or
interpreting int8 as int4.
while rewriting snprintf() I did not touch the actual functions
that convert number to ASCII digit string. In truth, if you
force PostgreSQL to use snprintf.c without my patch applied
it produces the same errors.
What can be wrong? GCC bug? The one I use is:
gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
Any thoughts?
On Mon, 28 Feb 2005 09:17:20 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Nicolai Tufar wrote:
Linux and Solaris 10 x86 pass regression tests fine when I force the use
of new
snprintf(). The problem should be win32 - specific. I will
investigate it throughly
tonight. Can someone experienced in win32 what can possibly be the
problem?
Yea, I am confused too because my BSD uses the new snprintf.c code was
well. Magnus, what failures are you seeing on Win32?
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] bitmap AM design
Here's the design of bitmap AM I'm planning to implement. I've discussed it
with Neil, but I'm willing to get more feedback on it.
There are going to be 1 metapage, 1 list of CTIDs (LOC), one list
of attribute values (LOV, including attributes for multi-column indexes) and a
bitmap for each entry in the LOV. Metapage will contain pointers to the LOC,
LOV will always start at page-1 and is organized as a 1-way chained list.
Neil suggested a very good way how to handle updates. Of course, it's not
necessary to strictly follow tuple layout in the table's heap, as I wanted
to do initially. All that's needed, is that bit positions in bitmaps would
be tied with CTID positions in LOC.
So, we can do simple insert (generally, that's how MVCC works for tuple
updates): when some tuple is updated, new CTID is added to the LOC and each
bitmap is extended by 1 bit.
On the other side (as Neil pointed), after VACUUM, we need to do some
maintenance of bitmap index to avoid situations when index contains duplicate
entries (in LOC and bitmaps) for the same CTID (value before marking tuple for
reuse and after actually reusing it). So far, the fastest way would be
recreating index, because the whole index designed for faster search/insert
operations and lacks effective reverse mapping (CTID-bit position-bit value)
functionality.
List of CTIDs is organized into an array of extents. Each extent has 2**i
pages ('i' is extent number in array). All pages for extent are allocated at
once, ensuring their IDs are sequential. So, we need to store only
BufferNumber of the first page in extent. LOC pages contain array of
ItemPointerData, it's size is detected at compile time. So, CTID for given bit
position can be obtained via only one ReadBuffer() call.
LOV pages store arrays of value-descriptors, each descriptor has a pointer to
the head of value's bitmap. Bitmaps are organized as 1-way chained list,
bitmap contents is compressed using Word-Aligned Hybryd method (similar to
RLE).
Neil suggested the other way of organizing bitmap storage: all bits for
given position are stored in one page (if it lacks space, new page is added
at the bootom), so we'll have a 2-dimensional bitmap storage.
This reduces amount of page reads during index scan, but for low-cardinality
indexes, we'll waste a lot of space per page, if each CTIDs slice is stored in
one page. On the other hand, it'll be hard to extend bitmap if we'll store
several CTID slices per page and some new value will be inserted (i.e. CTID
slice needs to be increased).
At the moment, I would implement the easiest method -- equality encoding (as
it's called in papers, bitmap per value). Neil's suggested techniques are
called range encoding. Josh Berkus on the irc suggested implementing several
encoding schemes as an option to the create index sql command.
What do you think?
I haven't looked at planner/executor yet.
If you have some questions, please, ask. Also, I'd like to tell that this is
my first time coding for PostgreSQL, thus I may use incorrect terminology.
Also, it takes much time to write anything, for the same reason. And yes,
I would really appreciate all kind of criticism on this design.
I've started to implement AM, I need to register am* functions, what OIDs
should use to register them in include/catalog/pg_proc.h?
Waiting for your feedback.
--
Victor Y. Yegorov
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] snprintf causes regression tests to fail
[EMAIL PROTECTED] writes: Do we have any idea about what format string causes the regression failure? I'll bet the problem is that configure.in is doing things in the wrong order: it computes INT64_FORMAT against the system printf before deciding we should use our own printf. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SQL99 Hierarchical queries
I'm curious what kind of performance differences there would be over using something like the nested-set model? Would this be faster, or slower? On Thu, 2005-02-24 at 13:02 +0300, Evgen Potemkin wrote: Hi hackers! I have done initial implementation of SQL99 WITH clause (attached). It's now only for v7.3.4 and haven't a lot of checks and restrictions. It can execute only simple WITH queries like WITH tree AS (SELECT id,pnt,name,1::int AS level FROM t WHERE id=0 UNION SELECT t.id,t.pnt,t.name,tree.level+1 FROM t JOIN tree ON tree.id=t.pnt ) SELECT * FROM tree; It would be great if someone with knowledge of Pg internals can make a kind of code review and make some advices how to better implement all this. Regards, Evgen. ---(end of broadcast)--- TIP 3: 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 -- Mike Benoit [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [HACKERS] SQL99 Hierarchical queries
On Mon, 28 Feb 2005, Evgen Potemkin wrote: Ok, I'm started porting it to 8.0.1 and will fix this also. By the way, did you know any test suit for such queries? To make some regression test. Hello, I can find some examples on internet and prepare regression tests. I think PostgreSQL can support all syntax H.Q. Is more easy created question via Oracle syntax, and processing is faster (maybe better optimalisation now), than ANSI WITH syntax. Can You add support for clausule VALUE? Pavel Stehule ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] serial as FK ?
On Mon, 28 Feb 2005, Stephan Szabo wrote: On Mon, 28 Feb 2005, Oleg Bartunov wrote: what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ? Serial isn't enough to guarantee uniqueness as required by foreign keys. you're certainly right ! Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] snprintf causes regression tests to fail
Neither Bruce's nor subsequent Tom's patch did not fix the issue. The command used is: make maintainer-clean ./configure make make install make check It should have be fine to recompile the source code completely. I attach the resulting config.log. May be it will give a clue. Regression test failure are in the same places as previous ones. Best regards, Nicolai On Mon, 28 Feb 2005 16:29:57 -0500 (EST), Bruce Momjian pgman@candle.pha.pa.us wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Ah, the problem was introduced here: Right, it was my fault. The problem is that the PGAC_FUNC_PRINTF_ARG_CONTROL call was moved below the printf 64-bit tests. This commited patch moves PGAC_FUNC_PRINTF_ARG_CONTROL which is after we know AC_TRY_RUN works and just before printf 64-bit args are tested. This patch breaks things in a different way: you should not have moved the AC_LIBOBJ(snprintf) step. Also you randomly placed the arg-control test between a chunk of code and the comment describing same. Thanks. -- 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 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] snprintf causes regression tests to fail
Nicolai Tufar wrote: Neither Bruce's nor subsequent Tom's patch did not fix the issue. The command used is: make maintainer-clean ./configure make make install make check It should have be fine to recompile the source code completely. I attach the resulting config.log. May be it will give a clue. Regression test failure are in the same places as previous ones. No log attached. Please email the log to me privately. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Thread-safe snprintf() vsnprintf() and printf()
And while we are on it, I would like to submit minor
changes to make snprintf() vsnprintf() and printf()
functions in src/port/snprintf.c thread-safe.
Best regards,
Nicolai Tufar
Index: src/port/snprintf.c
===
RCS file: /projects/cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.7
diff -c -r1.7 snprintf.c
*** src/port/snprintf.c 28 Feb 2005 14:16:16 - 1.7
--- src/port/snprintf.c 28 Feb 2005 23:11:22 -
***
*** 82,105
* for string length. This covers a nasty loophole.
*
* The other functions are there to prevent NULL pointers from
! * causing nast effects.
**/
! /*static char _id[] = $PostgreSQL: pgsql/src/port/snprintf.c,v 1.7 2005/02/28 14:16:16 momjian Exp $;*/
! static char *end;
! static int SnprfOverflow;
int snprintf(char *str, size_t count, const char *fmt,...);
int vsnprintf(char *str, size_t count, const char *fmt, va_list args);
int printf(const char *format, ...);
! static void dopr(char *buffer, const char *format, va_list args);
int
printf(const char *fmt,...)
{
int len;
va_list args;
! static char* buffer[4096];
char* p;
va_start(args, fmt);
--- 82,103
* for string length. This covers a nasty loophole.
*
* The other functions are there to prevent NULL pointers from
! * causing nasty effects.
**/
! /*static char _id[] = $PostgreSQL: pgsql/src/port/snprintf.c,v 1.6 2005/02/22 04:57:24 momjian Exp $;*/
int snprintf(char *str, size_t count, const char *fmt,...);
int vsnprintf(char *str, size_t count, const char *fmt, va_list args);
int printf(const char *format, ...);
! static void dopr(char *buffer, const char *format, va_list args, char *end);
int
printf(const char *fmt,...)
{
int len;
va_list args;
! char* buffer[4096];
char* p;
va_start(args, fmt);
***
*** 127,136
int
vsnprintf(char *str, size_t count, const char *fmt, va_list args)
{
str[0] = '\0';
end = str + count - 1;
! SnprfOverflow = 0;
! dopr(str, fmt, args);
if (count 0)
end[0] = '\0';
return strlen(str);
--- 125,134
int
vsnprintf(char *str, size_t count, const char *fmt, va_list args)
{
+ char *end;
str[0] = '\0';
end = str + count - 1;
! dopr(str, fmt, args, end);
if (count 0)
end[0] = '\0';
return strlen(str);
***
*** 140,150
* dopr(): poor man's version of doprintf
*/
! static void fmtstr(char *value, int ljust, int len, int zpad, int maxwidth);
! static void fmtnum(long_long value, int base, int dosign, int ljust, int len, int zpad);
! static void fmtfloat(double value, char type, int ljust, int len, int precision, int pointflag);
! static void dostr(char *str, int cut);
! static void dopr_outch(int c);
static char *output;
--- 138,148
* dopr(): poor man's version of doprintf
*/
! static void fmtstr(char *value, int ljust, int len, int zpad, int maxwidth, char *end);
! static void fmtnum(long_long value, int base, int dosign, int ljust, int len, int zpad, char *end);
! static void fmtfloat(double value, char type, int ljust, int len, int precision, int pointflag, char *end);
! static void dostr(char *str, int cut, char *end);
! static void dopr_outch(int c, char *end);
static char *output;
***
*** 154,160
#define FMTCHAR 4
static void
! dopr(char *buffer, const char *format, va_list args)
{
int ch;
long_long value;
--- 152,158
#define FMTCHAR 4
static void
! dopr(char *buffer, const char *format, va_list args, char *end)
{
int ch;
long_long value;
***
*** 417,427
case '%':
break;
default:
! dostr(???, 0);
}
break;
default:
! dopr_outch(ch);
break;
}
}
--- 415,425
case '%':
break;
default:
! dostr(???, 0, end);
}
break;
default:
! dopr_outch(ch, end);
break;
}
}
***
*** 448,474
case FMTSTR:
fmtstr(fmtparptr[i]-value, fmtparptr[i]-ljust,
fmtparptr[i]-len, fmtparptr[i]-zpad,
! fmtparptr[i]-maxwidth);
break;
case FMTNUM:
fmtnum(fmtparptr[i]-numvalue, fmtparptr[i]-base,
fmtparptr[i]-dosign, fmtparptr[i]-ljust,
! fmtparptr[i]-len, fmtparptr[i]-zpad);
break;
case FMTFLOAT:
fmtfloat(fmtparptr[i]-fvalue, fmtparptr[i]-type,
fmtparptr[i]-ljust, fmtparptr[i]-len,
! fmtparptr[i]-precision, fmtparptr[i]-pointflag);
break;
case FMTCHAR:
! dopr_outch(fmtparptr[i]-charvalue);
break;
}
format = fmtpar[i].fmtend;
goto nochar;
}
}
! dopr_outch(ch);
nochar:
/* nothing */
; /* semicolon required
Re: [HACKERS] idea for concurrent seqscans
On Sat, 2005-02-26 at 10:47 -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Assuming you're talkning about You might wonder why we don't order all the regression test queries explicitly to get rid of this issue once and for all. The reason is that that would make the regression tests less useful, not more, since they'd tend to exercise query plan types that produce ordered results to the exclusion of those that don't., good point. I can think of 2 ways around this: 1) Select into a temptable, then select out of it with an order by 2) Run the output through sort before doing the diff Is there any reason one of these wouldn't work? Like I said originally, we could certainly devise a solution if we needed to. I was just pointing out that this is a nontrivial consideration, and I don't want to buy into it if the patch proves to offer only marginal performance improvements. Yes, the starting place is performance prototyping. Jeff has sensibly started with that thought in his initial post. I would suggest that we used a new GUC enable_synch_scans = off, by default. to control whether this new behaviour was utilised. That way, all of the current tests would stand as-is. My feeling is that in general, we should only add tests, not alter existing ones. It would be straightforward, even if laborious, to add some additional tests that prove that this type of system feature returns correct SQL results. However, the key seems to be that the results of SQL runs without an ORDER BY would be timing dependant, so would actually be a wholly new type of test - we would need to run 1 on its own, then compare with 2 run together to check the same answer was still returned, possibly with a post execution external sort. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thread-safe snprintf() vsnprintf() and printf()
Patch applied. Thanks. --- Nicolai Tufar wrote: And while we are on it, I would like to submit minor changes to make snprintf() vsnprintf() and printf() functions in src/port/snprintf.c thread-safe. Best regards, Nicolai Tufar [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Execute and PortalSuspended needs explicit transaction to work?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm playing with Execute messages with a non-zero max number of rows so that I can get some PortalSuspended messages on Npgsql. After some testing, I could send an Execute message with 2 as the manx number of rows. After the second execute I get the following: portal does not exist Severity: ERROR Code: 34000 I noticed that I could only get it working if I explicitly create a transaction. I thought it could be some Sync() messages I was sending after the first execute, but when I removed them, I still get the problems. Is this by design? I mean, do I need to have an explicit transaction to get multiple executes work when getting portalsuspended messages? Or am I missing something? Thanks in advance. - -- Regards, Francisco Figueiredo Jr. Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - Science without religion is lame; religion without science is blind. ~ ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQiPOIP7iFmsNzeXfAQKGEAgAgCoF0BhPXXaS/T2Wa97T1SD90N1hWs6j DEfcfS2poXp+lLB64oLi1Q9gZAtzpHqDpYYsM5UA1JBtIE4X5ljOgtyKDdXhQVbM hn0rtRGYE7TLFSowVvODsu7qrchbAQVcE+rlKd91QmO9S7ibXxXaE//xAjGKvSng h4au7Id+dhZhjTJATFHBURV8IzJg3xK2/Kxg4BwY5p0yyUlBp+cHEv5ANBdvO1ms QVQt5QnUHobeIFfAVZvh466n36I8UhvMVaFfCxnzgPiGv2t9fnKBUEcGJrwMghm0 emx0O3Xni6xWBdW3R/aHo+XoARfwdNiW89fm2YKxWPjGzqTZHjfjng== =C5uE -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [JDBC] Where are we on stored procedures?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Schaber wrote: | Hi, Francisco, | | Francisco Figueiredo Jr. schrieb: | | |In fact, I think people keep requesting me support on Npgsql for that |because MS Sql server supports it and they are porting their code to use |Postgresql and facing that difficult. | |Indeed, for (a) we could use an approach similar to Ms sql server. We |could have a way of the procedure say if it wanted to send the rows |affected information or not. |And about (b) I think that it is only on trivial cases that people |really want to use this feature :) | | | As you need to tweak the function/procedure source to implement (a), you | can also tweak the function/procedure to return the row cound and | whatever other diagnostics you need. Yeap, You are right. | | For newly implemented stored procedures, we could create a special | diagnostics result set that every procedure creates. This usually | contains some success/error information, but the procedure could add | additional rows to it. | I think this could be a very good idea. I think you could create an special tag which would say to create this special resultset or not as, I think, not every stored procedure would need it. I think this would be very nice. Thanks Markus, for feedback. - -- Regards, Francisco Figueiredo Jr. Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - Science without religion is lame; religion without science is blind. ~ ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQiPPOf7iFmsNzeXfAQLFYQgAkiBLkYi8lKQ6NNJ2qP48nH8PmODoe4Wp FPB7lNvo9fLw0aw5rbztcu19FtvcJBJuFBFPc2LKImpszuJ2hcD02pTGqx3UxMR8 Yz3edTijCziHg8uBTiXQV0vHZ5WeE2/sEp+ve5heanDdzAcwLiCfDPxTR1XfVYaP AJfLIHspwVkrXcEbtgwEdPX91QG/cLYjcRR/fhiaH4s8I3Hi3o9ZitQ4bkdOdosw 10+TMrgzbtXKdEOhWu9xgvdcujksjKi1xXXXSwr+L5WPi4y9iohnIi6X9j9wWlOw fr9p2lYJgfzpq71Cl8dRlW+d0pRJFUlHiNaT/Adhzwsozc459Vix8Q== =Jcuy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Development Plans
Tom Lane wrote: I wouldn't mind seeing people be a little more vocal on the hackers list about what they plan to be doing, just so that there's not duplication of effort. pg_upgrade -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 3: 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: [HACKERS] Execute and PortalSuspended needs explicit transaction
Francisco Figueiredo Jr. wrote: After some testing, I could send an Execute message with 2 as the manx number of rows. After the second execute I get the following: portal does not exist Severity: ERROR Code: 34000 I noticed that I could only get it working if I explicitly create a transaction. I thought it could be some Sync() messages I was sending after the first execute, but when I removed them, I still get the problems. If you're sending any Sync messages at all between the two Executes, it will indeed cause problems as Sync causes any implicitly-opened transaction to be closed, which will in turn invalidate any non-holdable portals. Do you have a trace of all the messages sent? -O ---(end of broadcast)--- TIP 3: 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: [HACKERS] snprintf causes regression tests to fail
Nicolai Tufar wrote:
Regression test diff is attached.
It fails on the following tests:
int8
subselect
union
sequence
It fails to display correctly number 4567890123456789.
In output is shows -869367531. Apparent overflow or
interpreting int8 as int4.
while rewriting snprintf() I did not touch the actual functions
that convert number to ASCII digit string. In truth, if you
force PostgreSQL to use snprintf.c without my patch applied
it produces the same errors.
What can be wrong? GCC bug? The one I use is:
gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
I can confirm your failure in current sources on Win32:
template1=# create table test(x int8);
CREATE TABLE
template1=# insert into test values ('4567890123456789');
INSERT 17235 1
template1=# select * from test;
x
-869367531
(1 row)
and it knows it is a large number:
template1=# select * from test where x 1000::int8;
x
-869367531
(1 row)
template1=# select * from test where x 1000::int8;
x
---
(0 rows)
I am going to add some debugs to see what is being passed to *printf().
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] mysterious log output
I keep seeing the following log output around every 5 minutes:
2005-02-28 23:25:05 [8646] LOG: 0: QUERY STATISTICS
DETAIL: ! system usage stats:
! 0.005023 elapsed 0.00 user 0.00 system sec
! [537.13 user 44.86 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 0/4 [848810/1849693] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [0/0] voluntary/involuntary context switches
! buffer usage stats:
! Shared blocks: 0 read, 0 written, buffer hit
rate = 100.00%
! Local blocks: 0 read, 0 written, buffer hit
rate = 0.00%
! Direct blocks: 0 read, 0 written
LOCATION: ShowUsage, postgres.c:3199
The server is postgresql 7.4, running on debian linux. According to
postgres.c, it should be outputting due to GUC, however I verified that all
of the log_*_stats lines in the postgresql.conf are turned off and also
verified those GUC's are off in the show all; output... here's the relevant
bits.
log_connections| off
log_duration | off
log_error_verbosity| verbose
log_executor_stats | off
log_hostname | off
log_min_duration_statement | 5000
log_min_error_statement| info
log_min_messages | notice
log_parser_stats | off
log_pid| on
log_planner_stats | off
log_source_port| off
log_statement | off
log_statement_stats| off
log_timestamp | on
the only thing real sketchy about this is that it always seems to be on the
same pid (8646) and if I turn query logging on I see the following executed
right before this happens:
2005-03-01 00:25:08 [8646] LOG: 0: statement: select
_rv.cleanupEvent();
LOCATION: pg_parse_query, postgres.c:464
now according to the slony folks, there is nothing in slony that modifys the
logging output... so assuming that's true, anyone have any ideas on what
might be causing this logging?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] snprintf causes regression tests to fail
Bruce Momjian wrote:
I can confirm your failure in current sources on Win32:
template1=# create table test(x int8);
CREATE TABLE
template1=# insert into test values ('4567890123456789');
INSERT 17235 1
template1=# select * from test;
x
-869367531
(1 row)
and it knows it is a large number:
template1=# select * from test where x 1000::int8;
x
-869367531
(1 row)
template1=# select * from test where x 1000::int8;
x
---
(0 rows)
I am going to add some debugs to see what is being passed to *printf().
I have not found the solution yet but am heading to bed. My next guess
is that Win32 isn't handling va_arg(..., long long int) properly.
--
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 8: explain analyze is your friend
Re: [HACKERS] mysterious log output
Robert Treat [EMAIL PROTECTED] writes: I keep seeing the following log output around every 5 minutes: 2005-02-28 23:25:05 [8646] LOG: 0: QUERY STATISTICS This has to be coming from exec_simple_query(): if (save_log_statement_stats) ShowUsage(QUERY STATISTICS); so *something* is turning on log_statement_stats. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SQL99 Hierarchical queries
Mike, I'm curious what kind of performance differences there would be over using something like the nested-set model? Would this be faster, or slower? The answer is yes.;-) Which tree structures you use depends on what you're trying to accomplish and what your use case is. There are some structures (for example, heirarchical org charts) for which nested sets can't be beat. There are plenty of reasons to implement other tree structures, such as graphs, cycles, and delimited lists depending on what you're trying to depict. What WITH is going to replace, if anything, is the simple adjacency list structure. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bitmap AM design
Victor Y. Yegorov [EMAIL PROTECTED] writes: Neil suggested a very good way how to handle updates. Of course, it's not necessary to strictly follow tuple layout in the table's heap, as I wanted to do initially. All that's needed, is that bit positions in bitmaps would be tied with CTID positions in LOC. So, we can do simple insert (generally, that's how MVCC works for tuple updates): when some tuple is updated, new CTID is added to the LOC and each bitmap is extended by 1 bit. The other stuff you mentioned implies that an insertion therefore requires exclusive lock on the index (because you may have to relocate everything in sight to add one more CTID slot). On the other side (as Neil pointed), after VACUUM, we need to do some maintenance of bitmap index to avoid situations when index contains duplicate entries (in LOC and bitmaps) for the same CTID (value before marking tuple for reuse and after actually reusing it). So far, the fastest way would be recreating index, I can't believe you are seriously suggesting that it's OK to force every VACUUM to rebuild the index from scratch. We already get far too many complaints about the time needed for VACUUM. I don't think we really need any more fundamentally nonconcurrent index types :-( I've started to implement AM, I need to register am* functions, what OIDs should use to register them in include/catalog/pg_proc.h? Anything the unused_oids script reports as free. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
