Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Alvaro Herrera" <[EMAIL PROTECTED]> writes: >>> On what platforms does ioctl() fail? > >> On ssh for example. > > That'd certainly be a showstopper if true, but it seems to be okay for > me. ssh'ing from an xte

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Joshua D. Drake
Bruce Momjian wrote: For example, if I want to send wide psql output in email, right now I just send it wide or use \x. With 'wrapped' I can set it to 72 columns and get something I can email to people. I could copy it from my screen, but if the output is more than a screen full it is much har

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Joshua D. Drake wrote: > Bruce Momjian wrote: > > We have discussed having a formatting mode where aligned output switches > > to expanded output when the row is too wide. One idea would be to > > create an 'auto' mode that would display in aligned, or wrapped if that > > doesn't fit, or expanded

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Joshua D. Drake
Bruce Momjian wrote: interactive mode. In fact, it is hard to justify our current interactive behavior of a row just overflowing the screen width and moving to the next line. We have gotten used to it, but it is certainly not very user-friendly. +1 We have discussed having a formatting mo

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Tom Lane
Robert Treat <[EMAIL PROTECTED]> writes: > Perhaps a better option would be to implement Merge per spec, and then > implement a "replace into" command for the oltp scenario. This way you keep > the spec behavior for the spec syntax, and have a clearly non-spec command > for non-spec behavior.

Re: [HACKERS] Standard metadata queries

2008-04-24 Thread Decibel!
On Apr 24, 2008, at 1:01 PM, Steve Atkins wrote: I've been chatting with the Trolltech folks about the implementation of the Qt wrapper around libpq, and the issue of how to properly do metadata queries came up. That is things like "What are the column names and types of the primary key of t

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Bruce Momjian wrote: > > Trying to join the two decisions means that nobody will be happy. If you ssh > > in you won't get wrapped format, if you redirect to a file and specify > > wrapped > > format explicitly you'll be frustrated that you're still not getting it. And > > if you do want those thi

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > I am not excited about 'wrapped-interactive' and 'wrapped-all' formats. > > Do you have some other idea in mind? > > Some other idea for the name of it? Not particularly. I like your later > suggestion of "auto". Perhaps ju

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Robert Treat
On Thursday 24 April 2008 12:19, Tom Lane wrote: > Decibel! <[EMAIL PROTECTED]> writes: > > That really strikes me as taking the "MySQL route". If push comes to > > shove, I'll take a MERGE with race conditions over no merge at all, > > but I think it's very important that it does the right thing.

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > "Alvaro Herrera" <[EMAIL PROTECTED]> writes: >> On what platforms does ioctl() fail? > On ssh for example. That'd certainly be a showstopper if true, but it seems to be okay for me. ssh'ing from an xterm window, and running psql on the remote side, I c

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > I am not excited about 'wrapped-interactive' and 'wrapped-all' formats. > Do you have some other idea in mind? Some other idea for the name of it? Not particularly. I like your later suggestion of "auto". Perhaps just "wrapped" and "auto"? > I can't

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Alvaro Herrera" <[EMAIL PROTECTED]> writes: > On what platforms does ioctl() fail? On ssh for example. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Standard metadata queries

2008-04-24 Thread Steve Atkins
On Apr 24, 2008, at 2:22 PM, Tom Lane wrote: Steve Atkins <[EMAIL PROTECTED]> writes: On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote: I believe the information_schema is standard. Standard, but woefully incomplete (by design). Sure, because it's restricted to standardized concepts.

Re: [HACKERS] Standard metadata queries

2008-04-24 Thread Tom Lane
Steve Atkins <[EMAIL PROTECTED]> writes: > On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote: >> I believe the information_schema is standard. > Standard, but woefully incomplete (by design). Sure, because it's restricted to standardized concepts. Do the adapters in question need to obtain inf

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > Peter Eisentraut wrote: > > > > > > I think it is best not to look at $COLUMNS at all. If the output is to a > > > terminal, then use ioctl to query the terminal. And provide a \pset > > > command > > > to set a width explicitly, which can a

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Alvaro Herrera
Bruce Momjian escribió: > Peter Eisentraut wrote: > > > > I think it is best not to look at $COLUMNS at all. If the output is to a > > terminal, then use ioctl to query the terminal. And provide a \pset > > command > > to set a width explicitly, which can apply in all cases. > > Yes, that is

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > I think the API in the patch is the best I am going to do to keep > > everyone happy --- 'wrapped' doesn't affect file/pipe output unless you > > also tell it the width you want. Most interactive users are going to > > set '

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Greg's suggestion is to use $COLUMNS if the width can't be determined > > because the output is not directly to the screen. ?$COLUMNS is updated > > by many shells. > > I think it is best not to look at $COLUMNS at all. If the output is to a > t

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Peter Eisentraut
Bruce Momjian wrote: > Greg's suggestion is to use $COLUMNS if the width can't be determined > because the output is not directly to the screen.  $COLUMNS is updated > by many shells. I think it is best not to look at $COLUMNS at all. If the output is to a terminal, then use ioctl to query the t

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Peter Eisentraut
Bruce Momjian wrote: > 'ls' and 'ls | more' generate different outputs, and I have never heard > anyone call that "bunk". bunk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > I think the API in the patch is the best I am going to do to keep > everyone happy --- 'wrapped' doesn't affect file/pipe output unless you > also tell it the width you want. Most interactive users are going to > set 'wrapped' and never set the width

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > 'ls' and 'ls | more' generate different outputs, and I have never heard > > anyone call that "bunk". > > The analogue of that would be making psql default to wrapped mode if isatty is > true and normal mode if it's false. I

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Chris Browne
[EMAIL PROTECTED] (Decibel!) writes: > On Apr 22, 2008, at 1:17 PM, Gregory Stark wrote: >> "Simon Riggs" <[EMAIL PROTECTED]> writes: >> >>> As I've said elsewhere, we could have it lock each row, its just more >>> overhead if we do and not necessary at all for bulk data merging. >>> >>> I'll pres

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Simon Riggs
On Thu, 2008-04-24 at 12:19 -0400, Tom Lane wrote: > Decibel! <[EMAIL PROTECTED]> writes: > > That really strikes me as taking the "MySQL route". If push comes to > > shove, I'll take a MERGE with race conditions over no merge at all, > > but I think it's very important that it does the right t

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Aidan Van Dyk wrote: -- Start of PGP signed section. > * Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]: > > > I am confused exactly what people want changed in the patch. Some want > > no control over wrapping in file output, and others want $COLUMN to > > control column file output. The onl

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > 'ls' and 'ls | more' generate different outputs, and I have never heard > anyone call that "bunk". The analogue of that would be making psql default to wrapped mode if isatty is true and normal mode if it's false. I wouldn't be entirely against that b

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Aidan Van Dyk
* Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]: > I am confused exactly what people want changed in the patch. Some want > no control over wrapping in file output, and others want $COLUMN to > control column file output. The only person I am seeing code from is > Greg Stark, but I think mos

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
bruce wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > You are going to need to find community members who support your > > > analysis if you want to make any headway in changing the patch. > > > > Let's turn that around, shall we? I think at this point it's *you* > >

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > You are going to need to find community members who support your > > analysis if you want to make any headway in changing the patch. > > Let's turn that around, shall we? I think at this point it's *you* > that are standing alone and

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > You are going to need to find community members who support your > analysis if you want to make any headway in changing the patch. Let's turn that around, shall we? I think at this point it's *you* that are standing alone and need to find someone who ag

Re: [HACKERS] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables

2008-04-24 Thread Bruce Momjian
Added to TODO: * Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php

Re: [HACKERS] Standard metadata queries

2008-04-24 Thread Steve Atkins
On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote: On Thu, 24 Apr 2008 11:01:13 -0700 Steve Atkins <[EMAIL PROTECTED]> wrote: I've been chatting with the Trolltech folks about the implementation of the Qt wrapper around libpq, and the issue of how to properly do metadata queries came up. Th

Re: [HACKERS] Standard metadata queries

2008-04-24 Thread Joshua D. Drake
On Thu, 24 Apr 2008 11:01:13 -0700 Steve Atkins <[EMAIL PROTECTED]> wrote: > I've been chatting with the Trolltech folks about the implementation > of the Qt wrapper around libpq, and the issue of how to properly do > metadata queries came up. That is things like "What are the column > names

[HACKERS] Standard metadata queries

2008-04-24 Thread Steve Atkins
I've been chatting with the Trolltech folks about the implementation of the Qt wrapper around libpq, and the issue of how to properly do metadata queries came up. That is things like "What are the column names and types of the primary key of this table, and what index enforces it?" or "What

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Brendan Jurd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 25, 2008 at 3:46 AM, Tom Lane wrote: > alter table t1 add column f2 int not null; > > transformAlterTableStmt will produce an AT_AddColumn subcommand > containing a ColumnDef with is_not_null = false, followed by an > AT_SetNotNull sub

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > My point is that we should do what most people _expect_, and the > > majority of people here have stated they don't think wrap should modify > > the file output _by_ _default_. > > > > People who want a specific width for fil

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Tom Lane
I wrote: > So somehow the constraint-validation code isn't getting applied in > this case. I suspect you'll find it's a pretty localized fix. I traced through this and found that for alter table t1 add column f2 int not null; transformAlterTableStmt will produce an AT_AddColumn subcommand conta

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > My point is that we should do what most people _expect_, and the > majority of people here have stated they don't think wrap should modify > the file output _by_ _default_. > > People who want a specific width for files should be setting their > desire

Re: [HACKERS] 8.3 / 8.2.6 restore comparison

2008-04-24 Thread Bruce Momjian
Added to TODO: > o Impove COPY performance > > http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php --- Heikki Linnakangas wrote: > Bruce Momjian wrote: > > Heikki, are there any TODO items here?

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Tom Lane
I wrote: > I think the bug here is that ADD COLUMN NOT NULL has to fail if > there's not a default expression supplied (except maybe we could > allow it if the table contains no rows). ISTM we got this right > in the past, wonder why it's not working now ... Hm, we do get it right if PRIMARY KEY

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Brendan Jurd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 25, 2008 at 2:27 AM, Tom Lane wrote: > "Brendan Jurd" writes: > > transformIndexConstraint sets the is_not_null flag on the ColumnDefs > > associated with the primary key. That works great in a CREATE TABLE > > context, but in ADD COL

Re: [HACKERS] libpq object hooks -- needs copy result

2008-04-24 Thread Andrew Chernow
Merlin Moncure wrote: With an eye towards sideband utility, we are suggesting: PQcopyResult(PGresult *dest, const PGresult *src, int numAttributes, PGresAttDesc *attDescs, int options); Small correction on that prototype. PGresult * PQcopyResult(const PGresult *src, int numAttributes, PGre

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Bruce Momjian
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Tom Lane wrote: > > >> Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Is this TODO item done? > > >>> * Allow index scans to return matching index keys > > >>> > > >>> http://archives.postgresql.org/pgsql-h

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Ah, OK, exactly what should the TODO item text be? Can you modify the > TODO? I don't understand the TODO text I had. What I thought the TODO was about was extending the indexam API so that the actual key values stored in the index could be retrieved (

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Tom Lane
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > Well, for these two: > * For Highly Non-Unique Data we can use Duplicate Compression > * Multi-Column Leading Value Compression - if you have a multi-column > You don't need any new logic at all. If _bt_compare says they're equal > you can compa

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Peter Eisentraut wrote: > > >> Well, the feature is labeled "psql wraps at window width". If the > > >> output > > >> isn't on a window, then it shouldn't wrap. > > > > > \pset columns will wrap to the sp

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Is this TODO item done? > >>> * Allow index scans to return matching index keys > >>> > >>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php > >> > >

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Peter Eisentraut wrote: > >> Well, the feature is labeled "psql wraps at window width". If the output > >> isn't on a window, then it shouldn't wrap. > > > \pset columns will wrap to the specified width for file output. > > I agree

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Martijn van Oosterhout
Well, for these two: > >> * For Highly Non-Unique Data we can use Duplicate Compression > >> * Multi-Column Leading Value Compression - if you have a multi-column You don't need any new logic at all. If _bt_compare says they're equal you can compact them. The long similar case is harder, ISTM the

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > >> b) If you dump to a file it will still respect COLUMNS. This might be a bit > >>weird since bash sets COLUMNS so your file width will be based on the > >> size > >>of your terminal. But people also do things like COLUMNS=120 psql -o f > >> ... > > > > No, that wi

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> Well, the feature is labeled "psql wraps at window width". If the output >> isn't on a window, then it shouldn't wrap. > \pset columns will wrap to the specified width for file output. I agree with Peter: that's a seriously

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Tom Lane
"Brendan Jurd" <[EMAIL PROTECTED]> writes: > transformIndexConstraint sets the is_not_null flag on the ColumnDefs > associated with the primary key. That works great in a CREATE TABLE > context, but in ADD COLUMN, when we haven't created the column yet, > this means that the column is created with

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Decibel!
On Apr 24, 2008, at 10:43 AM, Bruce Momjian wrote: Bruce asked if these should be TODOs... Index compression is possible in many ways, depending upon the situation. All of the following sound similar at a high level, but each covers a different use case. * For Long, Similar data e.g. Text w

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> writes: > Is this TODO item done? >>> * Allow index scans to return matching index keys >>> >>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php >> >> We've done as much as we want to

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Uh, if you do that I am not sure what the user would want. I duplicated > what we do with PAGER and unless there is a clear mandate I think we > should keep the wrapping detection consistent with that; we have gotten > no complaints. Pager will not

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Simon Riggs
On Thu, 2008-04-24 at 11:43 -0400, Bruce Momjian wrote: > > Index compression is possible in many ways, depending upon the > > situation. All of the following sound similar at a high level, but each > > covers a different use case. > > > > * For Long, Similar data e.g. Text we can use Prefix Comp

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Tom Lane
Decibel! <[EMAIL PROTECTED]> writes: > That really strikes me as taking the "MySQL route". If push comes to > shove, I'll take a MERGE with race conditions over no merge at all, > but I think it's very important that it does the right thing. Just > because the spec doesn't say anything about

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Is this TODO item done? > > * Allow index scans to return matching index keys > > > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php > > We've done as much as we want to do of what that message sugges

Re: [HACKERS] Per-table random_page_cost for tables that we know are always cached

2008-04-24 Thread Decibel!
On Apr 23, 2008, at 12:31 AM, Greg Smith wrote: Jim threw out that you can just look at the page hit percentages instead. That's not completely true. If you've had some nasty query blow out your buffer cache, or if the server has been up a looong time and the total stas don't really reflect

Re: [HACKERS] Is this TODO item done?

2008-04-24 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Is this TODO item done? > * Allow index scans to return matching index keys > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php We've done as much as we want to do of what that message suggests, but it seems to have

Re: [HACKERS] MERGE Specification

2008-04-24 Thread Decibel!
On Apr 22, 2008, at 3:20 PM, Martijn van Oosterhout wrote: On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote: But no matter how this is done, I think we need to handle the race conditions, and handle them by default. If people *really* know what they're doing, they can disable the row lo

[HACKERS] hm, why isn't SGT in the default timezone abbreviations list?

2008-04-24 Thread Tom Lane
According to the zic database, SGT is the recognized abbreviation for Singapore time, and there are no other conflicting uses. I wonder why it isn't in either the Default or Asia lists ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Peter Eisentraut wrote: > Am Donnerstag, 24. April 2008 schrieb Gregory Stark: > > b) If you dump to a file it will still respect COLUMNS. This might be a bit > > ? ?weird since bash sets COLUMNS so your file width will be based on the > > size of your terminal. But people also do things like COLUM

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Bruce Momjian
Simon Riggs wrote: > > > Many users would be very interested if we could significantly reduce the > > > size of the main index on their largest tables. > > > > Yes, basically GIT allows index compression for clustered tables, and > > stated that way it is clear it would be a big feature if we had

[HACKERS] Is this TODO item done?

2008-04-24 Thread Bruce Momjian
Is this TODO item done? * Allow index scans to return matching index keys http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.c

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Brendan Jurd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 24, 2008 at 7:13 PM, Richard Huxton wrote: > Kaloyan Iliev wrote: > > r=# CREATE TABLE test( a text, b int); > > CREATE TABLE > > r=# INSERT INTO test VALUES ('test',1); > > INSERT 0 1 > > r=# ALTER TABLE test ADD COLUMN id INT NOT NULL P

Re: [HACKERS] WIP: psql default banner patch

2008-04-24 Thread Peter Eisentraut
Am Mittwoch, 23. April 2008 schrieb Andrew Dunstan: > No, I mean you could put it in your psql prompt. > > 8.3 dbname> You can put variables in your prompt. The VERSION variable exists, but it is a bit verbose. Perhaps it can be trimmed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Peter Eisentraut
Am Donnerstag, 24. April 2008 schrieb Gregory Stark: > b) If you dump to a file it will still respect COLUMNS. This might be a bit >    weird since bash sets COLUMNS so your file width will be based on the > size of your terminal. But people also do things like COLUMNS=120 psql -o f > ... Well, th

Re: [HACKERS] Avoiding a needless failure of PITR

2008-04-24 Thread Simon Riggs
On Thu, 2008-04-24 at 23:25 +0900, Fujii Masao wrote: > Hi, > > PITR always fails in finding the archived log file with wrong size. But, > I think that we can continue PITR if .ready file of the same name exists > in XLOGDIR/archive_status, ie the complete file might exist in XLOGDIR. > > I want

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Alvaro Herrera
Bruce Momjian escribió: > > b) If you dump to a file it will still respect COLUMNS. This might be a bit > >weird since bash sets COLUMNS so your file width will be based on the > > size > >of your terminal. But people also do things like COLUMNS=120 psql -o f > > ... > > No, that will m

Re: [HACKERS] Avoiding a needless failure of PITR

2008-04-24 Thread Tom Lane
Fujii Masao <[EMAIL PROTECTED]> writes: > PITR always fails in finding the archived log file with wrong size. If the archived file is actually broken like that, it hardly seems prudent to keep going ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Bruce Momjian
Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > Gregory Stark wrote: > >> Earlier I suggested -- and nobody refuted -- that we should follow the > >> precedents of ls and man and other tools which need to find the terminal > >> width: Explicitly set width takes precedence alw

[HACKERS] Avoiding a needless failure of PITR

2008-04-24 Thread Fujii Masao
Hi, PITR always fails in finding the archived log file with wrong size. But, I think that we can continue PITR if .ready file of the same name exists in XLOGDIR/archive_status, ie the complete file might exist in XLOGDIR. I want to modify the implementation of PITR a little as follows. - In PITR

[HACKERS] libpq object hooks -- needs copy result

2008-04-24 Thread Merlin Moncure
We are trying to clean up the object hooks patch (on the libpq side) in time for the May commit fest. The last version we posted is here: http://www.nabble.com/libpq-object-hooks-patch-to16707707.html Everything for the most part works ok but there is a problem with the function 'PQmakeResult' wh

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Gregory Stark
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote: >> Index compression is possible in many ways, depending upon the >> situation. All of the following sound similar at a high level, but each >> covers a different use case. > > True,

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread ITAGAKI Takahiro
Simon Riggs <[EMAIL PROTECTED]> wrote: > * For Highly Non-Unique Data we can use Duplicate Compression > The latter is the technique used by Bitmap Indexes. Efficient, but not > useful for unique/nearly-unique data I heard that GIN has already had duplicate-compression feature. http://www.sai.m

Re: [HACKERS] Proposed patch - psql wraps at window width

2008-04-24 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: > >> Earlier I suggested -- and nobody refuted -- that we should follow the >> precedents of ls and man and other tools which need to find the terminal >> width: Explicitly set width takes precedence always, if it's not explicitly

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Simon Riggs
On Thu, 2008-04-24 at 13:13 +0200, Martijn van Oosterhout wrote: > On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote: > > Index compression is possible in many ways, depending upon the > > situation. All of the following sound similar at a high level, but each > > covers a different use c

Re: [HACKERS] Batch update of indexes on data loading

2008-04-24 Thread Simon Riggs
On Tue, 2008-02-26 at 09:08 +, Simon Riggs wrote: > I very much like the idea of index merging, or put another way: batch > index inserts. How big do the batch of index inserts have to be for us > to gain benefit from this technique? Would it be possible to just buffer > the index inserts insi

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Martijn van Oosterhout
On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote: > Index compression is possible in many ways, depending upon the > situation. All of the following sound similar at a high level, but each > covers a different use case. True, but there is one significant difference: > * For Long, Simil

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Simon Riggs
On Wed, 2008-04-23 at 19:43 -0700, Ron Mayer wrote: > Tom Lane wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > >> On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote: > >>> To be acceptable, a GIT patch would have to be optional and it > >>> ... > > I was considering a new pg_index column. Or e

Re: [HACKERS] [GENERAL] I think this is a BUG?

2008-04-24 Thread Richard Huxton
Kaloyan Iliev wrote: Hi, I find something very interesting which I think is a bug and I want to discuss it. --- Here is the example1: 1.I create a table without PK; 2.Insert 1 row; 3.I ADD PK; 4.When I select all ID's are

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Simon Riggs
On Wed, 2008-04-23 at 22:26 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > GIT significantly reduces the size of clustered indexes, greatly > > improving the number of index pointers that can be held in memory for > > very large indexes. That translates directly into a reduction in I/O for >

Re: [HACKERS] Index AM change proposals, redux

2008-04-24 Thread Teodor Sigaev
Interesting. Does this mean that down the road a postgis index might be GIT-ified? Only if GiST will support GIT, but I don't follow on this discussion. In any case, GIT on GiST will not be so effective as on Btree, because GiST doesn't guarantee that all close values will be close in index: