[HACKERS] Surfacing qualifiers

Folks, Neil Conway sent me a patch that sketched out a plan to make quals visible to functions, and Korry Douglas filled in much of the rest of what you see attached here. Mistakes are all mine. :) Random observations: * It appears I've botched the call to deparse_context_for_plan in src/back

Re: [HACKERS] advancing snapshot's xmin

Le mercredi 26 mars 2008, Tom Lane a écrit : > whenever the number of active snapshots goes to zero Does this ever happen? I mean, if the way to avoid locking contention is to rely on a production system which let the service "breathe" from time to time, maybe there's something wrong in the reas

Re: [HACKERS] advancing snapshot's xmin

"Tom Lane" <[EMAIL PROTECTED]> writes: > "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: >> Neil Conway wrote: >>> If we're just updating MyProc->xmin, we only need to acquire >>> ProcArrayLock in shared mode, right? > >> In fact, do you need a lock at all? > > I think you probably do. GetSnapsh

Re: [HACKERS] Problem with site doc search

On Tue, Mar 25, 2008 at 3:01 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote: > Gurjeet Singh wrote: > > On Thu, Mar 6, 2008 at 5:01 PM, Gevik Babakhani <[EMAIL PROTECTED] > > > wrote: > > > > > No, it's still on the TODO. Gevik has also been looking a bit > > > a

Re: [HACKERS] Script binaries renaming

Bruce Momjian napsal(a): Where are we on this? Tom thinks we don't want this. TODO has: I plan to send survey on general list about it today. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

Re: [HACKERS] Script binaries renaming

Marc G. Fournier napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, March 25, 2008 22:51:53 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Uh, I think it is hard to make a case that 'createuser' is an appropriate name for a Postgres utility. On the other hand, we hav

Re: [HACKERS] Script binaries renaming

On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Where are we on this? Tom thinks we don't want this. TODO has: > > * Prefix command-line utilities like createuser with 'pg_' > > http://archives.postgresql.org/pgsql-hackers/2007-06/

Re: [HACKERS] Script binaries renaming

Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I always use psql with a commandline parameter, and the majority of other peoples scrip

Re: [HACKERS] Script binaries renaming

On Wed, 2008-03-26 at 13:21 +0100, Zdeněk Kotala wrote: > Magnus Hagander napsal(a): > > On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: > > > > >> Are we really prepared to break everyone's scripts for this? > > > > I wonder how many people actually use those commands :-) I know I always >

Re: [HACKERS] Surfacing qualifiers

David Fetter wrote: Folks, Neil Conway sent me a patch that sketched out a plan to make quals visible to functions er, what? Please explain what this means, why it might be useful. Example(s) would help. * In PL/Perl, $_TD->{_quals} gets the qualifiers, but they really should go in

Re: [HACKERS] Script binaries renaming

Magnus Hagander napsal(a): On Wed, 2008-03-26 at 13:21 +0100, Zdeněk Kotala wrote: Magnus Hagander napsal(a): On Tue, 2008-03-25 at 21:59 -0400, Tom Lane wrote: Are we really prepared to break everyone's scripts for this? I wonder how many people actually use those commands :-) I know I al

Re: [HACKERS] Script binaries renaming

Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb rather than using autovacuum

Re: [HACKERS] Script binaries renaming

Andrew Dunstan napsal(a): Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch updates by a single vacuumdb r

Re: [HACKERS] Script binaries renaming

Zdeněk Kotala wrote: Andrew Dunstan napsal(a): Zdeněk Kotala wrote: Question is also how many users really use these commands. For example vacuumdb is not too important now when we have autovacuum. This is not true. Plenty of apps will quite reasonably choose to follow large batch update

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Tom Lane wrote: > The real question here is whether Windows' stat() is telling the truth > about how much filesystem space has actually been allocated to a file. > It seems entirely possible that it's not; but if it is, then I think we > have a problem. Has this been examined by a Windows hacker?

[HACKERS] Proposal: improve shutdown during online backup

I'm referring to the discussion in this thread: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00946.php As expressed in the thread, I think that there should not be a backup_label file in the data directory after a clean shutdown, because a) it's probably an oversight anyway (someone for

[HACKERS] having problem in rsync'ing cvs

Hi all, I was rsyncing a fresh copy of CVS repository, and suddenly, midway (around heap.c) rsync complained. When after many retries I couldn't start it, I restarted the OS. Since it is a VM running inside Vista (from where I could ping and browse anoncvs.postgresql.org), I restarted the

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Alvaro Herrera wrote: Tom Lane wrote: The real question here is whether Windows' stat() is telling the truth about how much filesystem space has actually been allocated to a file. It seems entirely possible that it's not; but if it is, then I think we have a problem. Has this been e

Re: [HACKERS] advancing snapshot's xmin

Dimitri Fontaine <[EMAIL PROTECTED]> writes: > Le mercredi 26 mars 2008, Tom Lane a écrit : >> whenever the number of active snapshots goes to zero > Does this ever happen? Certainly: between any two commands of a non-serializable transaction. In a serializable transaction the whole thing is a

Re: [HACKERS] having problem in rsync'ing cvs

On 27/03/2008, Gurjeet Singh <[EMAIL PROTECTED]> wrote: > Is the rsync daemon on anoncvs down? Is everyone else able to do rsync? > Possibly related; the Postgres git repository at http://repo.or.cz/w/PostgreSQL.git is showing the last commit at 25 hours ago. It's usually a bit more spry than tha

Re: [HACKERS] having problem in rsync'ing cvs

Gurjeet Singh escribió: > Is the rsync daemon on anoncvs down? Is everyone else able to do rsync? I can rsync with no issue. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] advancing snapshot's xmin

Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> I think you probably do. GetSnapshotData needs to be confident that the >> global xmin it computes is <= the xmin that any other backend might be >> about to store into its MyProc->xmin; how can you ensure that i

Re: [HACKERS] Surfacing qualifiers

Andrew Dunstan <[EMAIL PROTECTED]> writes: > David Fetter wrote: >> Neil Conway sent me a patch that sketched out a plan to make quals >> visible to functions > er, what? Please explain what this means, why it might be useful. It's utterly useless, because it only exposes a small fraction of the

Re: [HACKERS] Array behavior oddities

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > If any dimension is written as a slice, i.e. contains a colon, then all > > dimensions are treated as slices. > > > Is the the behavior of assuming an entry with no colon is a slice what > > we want, or are we just stuck with it?

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Can anybody tell me how filesystem space is allocated and point me to the sources if it's possible? I have some experience with programming for Windows and I'll try to investigate this problem. -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26,

[HACKERS] [GSoC] Need for advice on improving hash index performance

Hello, Hackers: I've post a question about GSoC before. [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk) http://archives.postgresql.org/pgsql-hackers/2008-03/msg00859.php Now, I start a new thread since the topic had been t

Re: [HACKERS] Script binaries renaming

Magnus Hagander <[EMAIL PROTECTED]> writes: > Another option then might be to simply deprecate their use, and > eventually get rid of them, instead of renaming them? I'd like to get rid of ipcclean immediately; it hasn't had any usefulness in years. The issue is larger than the proposed patch add

Re: [HACKERS] advancing snapshot's xmin

"Tom Lane" <[EMAIL PROTECTED]> writes: >> Consider a data loading job which has millions of INSERT statements in a >> file. >> Currently if you put them all in a transaction it takes a single snapshot and >> runs them all with the same snapshot. > >> If you reset xmin whenever you have no live sn

Re: [HACKERS] Script binaries renaming

Tom Lane napsal(a): Magnus Hagander <[EMAIL PROTECTED]> writes: Another option then might be to simply deprecate their use, and eventually get rid of them, instead of renaming them? I'd like to get rid of ipcclean immediately; it hasn't had any usefulness in years. +1 The issue is larger t

Re: [HACKERS] Script binaries renaming

Zdenek Kotala wrote: > Tom Lane napsal(a): > > Magnus Hagander <[EMAIL PROTECTED]> writes: > >> Another option then might be to simply deprecate their use, and > >> eventually get rid of them, instead of renaming them? > > > > I'd like to get rid of ipcclean immediately; it hasn't had any usefulne

Re: [HACKERS] Script binaries renaming

Zdenek Kotala <[EMAIL PROTECTED]> writes: >> There's an awful lot of names here that don't have any obvious >> connection to Postgres ... > Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same > output like pg_controldata. I think we can merge these commands. Now we're into change

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Andrew Dunstan <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> Tom Lane wrote: >>> The real question here is whether Windows' stat() is telling the truth >>> about how much filesystem space has actually been allocated to a file. >>> It seems entirely possible that it's not; but if it is, the

Re: [HACKERS] Script binaries renaming

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: There's an awful lot of names here that don't have any obvious connection to Postgres ... Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now w

Re: [HACKERS] advancing snapshot's xmin

Gregory Stark <[EMAIL PROTECTED]> writes: > Uhm, yeah, I somehow didn't write was I was thinking. I didn't mean to say we > would be taking a new snapshot for each INSERT but that we would be resetting > xmin for each INSERT. Whereas currently we only set xmin once when we set the > serializable sn

Re: [HACKERS] having problem in rsync'ing cvs

On Wed, Mar 26, 2008 at 7:56 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Gurjeet Singh escribió: > > > Is the rsync daemon on anoncvs down? Is everyone else able to do rsync? > > I can rsync with no issue. > I attempted again, and it seems to have started responding Seems like an intermi

Re: [HACKERS] advancing snapshot's xmin

Le mercredi 26 mars 2008, Tom Lane a écrit : > Dimitri Fontaine <[EMAIL PROTECTED]> writes: > > Le mercredi 26 mars 2008, Tom Lane a écrit : > >> whenever the number of active snapshots goes to zero > > Does this ever happen? > Certainly: between any two commands of a non-serializable transaction.

Re: [HACKERS] Script binaries renaming

Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change? Those programs don't have a

Re: [HACKERS] Script binaries renaming

Andrew Dunstan napsal(a): Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same output like pg_controldata. I think we can merge these commands. Now we're into change for the sake of change?

Re: [HACKERS] advancing snapshot's xmin

"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Uhm, yeah, I somehow didn't write was I was thinking. I didn't mean to say we >> would be taking a new snapshot for each INSERT but that we would be resetting >> xmin for each INSERT. Whereas currently we only se

Re: [HACKERS] [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

[EMAIL PROTECTED] (Bruce Momjian) writes: > Log Message: > --- > Strengthen warnings about using pg_dump's -i option. The proposed TODO item was not about doing this, it was about removing the option altogether. AFAICS it's a foot-gun and nothing else --- why do we have it? BTW, a point

[HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Log Message: > > --- > > Strengthen warnings about using pg_dump's -i option. > > The proposed TODO item was not about doing this, it was about removing > the option altogether. AFAICS it's a foot-gun and nothing else --- why

Re: [HACKERS] Surfacing qualifiers

On Wed, Mar 26, 2008 at 08:31:04AM -0400, Andrew Dunstan wrote: > David Fetter wrote: >> Folks, >> >> Neil Conway sent me a patch that sketched out a plan to make quals >> visible to functions >> > er, what? Please explain what this means, why it might be useful. > Example(s) would help. Right

Re: [HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> [EMAIL PROTECTED] (Bruce Momjian) writes: >>> Strengthen warnings about using pg_dump's -i option. >> >> The proposed TODO item was not about doing this, it was about removing >> the option altogether. AFAICS it's a foot-gun and nothi

Re: [HACKERS] [GSoC] Need for advice on improving hash index performance

On Wed, Mar 26, 2008 at 10:55:44PM +0800, Xiao Meng wrote: > Hello, Hackers: > > I've post a question about GSoC before. > [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is > it an acceptable idea to build index on Flash Disk) > http://archives.postgresql.org/pgsql-hackers/200

Re: [HACKERS] Surfacing qualifiers

On Wed, Mar 26, 2008 at 01:21:14PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > What happens now with dblink is that the remote table (more generally, > > the output of a fixed query) gets materialized into memory in its > > entirety, and if it's bigger than what's availabl

Re: [HACKERS] Surfacing qualifiers

David Fetter <[EMAIL PROTECTED]> writes: > What happens now with dblink is that the remote table (more generally, > the output of a fixed query) gets materialized into memory in its > entirety, and if it's bigger than what's available, it will crash the > backend or worse. This is utter nonsense.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> [EMAIL PROTECTED] (Bruce Momjian) writes: > >>> Strengthen warnings about using pg_dump's -i option. > >> > >> The proposed TODO item was not about doing this, it was about removing > >> the option altogether. AF

[HACKERS] Sending queries directly

Hello, I am creating an agent that runs alongside the postgres written in c++, I have a question: How send sql queries directly for the database without going need to make any connection? What I call function, which I use file? Thanks, -- Pedro Belmino. ---

[HACKERS] HELP

Hello, I am creating an agent that runs alongside the postgres written in c++, I have a question: How send sql queries directly for the database without going need to make any connection? What I call function, which I use file? Thanks, -- Pedro Belmino. --

Re: [HACKERS] Surfacing qualifiers

David Fetter <[EMAIL PROTECTED]> writes: > You mentioned in an earlier mail that the information exposed was > inadequate. Could you sketch out what information would really be > needed and where to find it? The main problem with what you suggest is that it'll fail utterly on join queries. AFAIC

Re: [HACKERS] Sending queries directly

Pedro Belmino wrote: I am creating an agent that runs alongside the postgres written in c++, I have a question: How send sql queries directly for the database without going need to make any connection? You can't. Why would you not want to open a connection? -- Heikki Linnakangas Enterprise

Re: [HACKERS] Surfacing qualifiers

David Fetter wrote: dblink is not a suitable framework for improving that situation. Maybe someday we'll have a proper implementation of SQL/MED ... This is intended to be a step or two along the way :) I'm still waiting to see an example of where you say this patch is even marg

Re: [HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> My proposal would be to continue to accept the option but just ignore it >> (ie, error out on version mismatch whether or not -i is given). This >> way we wouldn't break any scripts that use the option, but things would >> still be saf

Re: [HACKERS] Sending queries directly

Pedro Belmino wrote: Hello, I am creating an agent that runs alongside the postgres written in c++, I have a question: How send sql queries directly for the database without going need to make any connection? What I call function, which I use file? You can't. Why can't you use a connecti

Re: [HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> My proposal would be to continue to accept the option but just ignore it > >> (ie, error out on version mismatch whether or not -i is given). This > >> way we wouldn't break any scripts that use the option, but th

Re: [HACKERS] gcc 4.3 breaks ContribCheck in 8.2 and older.

On Tue, Mar 25, 2008 at 06:03:39PM -0400, Andrew Dunstan wrote: >> >> Patches committed, please re-enable the back branches so we can >> see what happens. > > I have tested this back as far as 8.0, and all seems OK. 7.4 passed too. Kurt -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> One point after looking back at the previous discussion is that the >> current version test is too strict: it will complain if your server is >> 8.2.7 and pg_dump is 8.2.6. We probably should not make a newer minor >> number a hard err

Re: [HACKERS] HELP

On Wed, Mar 26, 2008 at 11:10 PM, Pedro Belmino <[EMAIL PROTECTED]> wrote: > Hello, > I am creating an agent that runs alongside the postgres written in c++, I > have a question: How send sql queries directly for the database without > going need to make any connection? > What I call function, whi

Re: [HACKERS] Proposal: improve shutdown during online backup

On Wed, 2008-03-26 at 14:36 +0100, Albe Laurenz wrote: > I'm referring to the discussion in this thread: > http://archives.postgresql.org/pgsql-hackers/2007-11/msg00946.php > > As expressed in the thread, I think that there should not be > a backup_label file in the data directory after a clean sh

Re: [HACKERS] Sending queries directly

[EMAIL PROTECTED] ("Pedro Belmino") writes: > I am creating an agent that runs alongside the postgres written in > c++, I have a question: How send sql queries directly for the > database without going need to make any > connection? > What I > call function, which I use file? You don't do tha

Re: [HACKERS] Surfacing qualifiers

On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote: > I'm still waiting to see an example of where you say this patch is even > marginally useful. It's not hard to think of one: SELECT * FROM remote_table() WHERE x = 5; Applying the predicate on the remote database (pushing the predicate b

[HACKERS] Timing of parameter/variable name lookup vs legacy behaviors

I spent part of today looking at Gevik Babakhani's patch to let SQL-language functions refer to their parameters by name instead of just as $n. It's not ready to go yet but there are interesting definitional issues here, especially when you look ahead to using the same mechanism for resolving refe

Re: [HACKERS] Surfacing qualifiers

On Wed, Mar 26, 2008 at 02:26:41PM -0700, Neil Conway wrote: > On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote: > > I'm still waiting to see an example of where you say this patch is > > even marginally useful. > > It's not hard to think of one: > > SELECT * FROM remote_table() WHERE x =

[HACKERS] Windows shared_buffers limitations

Was working on some documentation today and I realized that I've taken for granted the lore about not using large values for shared_buffers in Windows without ever understanding why. Can someone explain what the underlying mechanism that causes that limitation is? From poking the archives I g

Re: [HACKERS] Script binaries renaming

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala <[EMAIL PROTECTED]> wrote: > Minimal me :-) and Solaris Architect committee have complain. Question is > also how many users really use these commands. For example vacuumdb is not > too

Re: [HACKERS] Surfacing qualifiers

Neil Conway <[EMAIL PROTECTED]> writes: > Certainly I agree with Tom that proper SQL/MED support requires > significant support from both the executor and the optimizer. This is > just a quick hack to take advantage of the existing predicate pushdown > logic -- I just thought it was a cute trick, n

Re: [HACKERS] Script binaries renaming

On Wed, 26 Mar 2008 19:28:49 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > Huh? I run a vacuumdb once a week on all my databases, even with > autovacuum turned on Yeah I have to agree. Autovacuum only solves the common data issues. There are still many, many issues that it can't solve. A

Re: [HACKERS] Proposal: improve shutdown during online backup

On Wed, 26 Mar 2008, Albe Laurenz wrote: 1) On "pg_ctl stop|restart -m smart", check if online backup is in progress and do not shutdown in this case (treat the online backup like an open connection). As long as you give a warning as to the cause. While you're in there, I think more outp

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Alvaro Herrera wrote: Tom Lane wrote: The real question here is whether Windows' stat() is telling the truth about how much filesystem space has actually been allocated to a file. It seems entirely possible that it's n

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >>> The real question here is whether Windows' stat() is telling the truth >>> about how much filesystem space has actually been allocated to a file. >> >> One thing that would be good is just to see who else can reproduce >> the original

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: The real question here is whether Windows' stat() is telling the truth about how much filesystem space has actually been allocated to a file. One thing that would be good is just to see who else can r

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: The real question here is whether Windows' stat() is telling the truth about how much filesystem space has actually been allocated to a file. One thing that would be good is just to see who else can r

Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT

Andrew Dunstan <[EMAIL PROTECTED]> writes: > I suspect that the size reported by stat() is a little delayed here, but > the file system is keeping proper track of it, so the lseek that tries > to extend the file fails at the right spot. Hmm. If it really works that way, one would hope Microsoft

[HACKERS] Planner/optimizer tool

I'm scoping a project to display the choices and plans the planner/optimizer considers while PostgreSQL develops a plan. It would be primarily a teaching tool but may be of use to users curious about the inner workings of the planner. This is in contrast with EXPLAIN, which provides informati