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:
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
large
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
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 else we'd have to
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, Similar
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 inside
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 case.
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
set then
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.
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, but there
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'
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
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 always, if it's
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
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 make the
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 to
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, the
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
-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 PRIMARY
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
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 it for
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 COLUMNS=120
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
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
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
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
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 suggests,
but it
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 it
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 Compression
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 work
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 do of what that
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
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
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 bad idea.
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 will make the
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 there
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 with Peter:
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
We've done as much as we
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 specified width for file
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 compact
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
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-hackers/2007-03/msg01079.php
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,
-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 COLUMN,
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
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?
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
desired width
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
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 files should be
-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
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
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 and
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.
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
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
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 need to
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*
that are
* 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 most
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 but I
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 only person
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 thing. Just
[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 presume we want locking
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 wouldn't be
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 so it
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
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
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
terminal,
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 'wrapped' and
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 pretty much
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 apply in all
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 info
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.
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)
To
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 think of
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 can see
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. Just
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 just wrapped and
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 things so
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
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.
In
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
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 if that
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
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 xterm window, and
84 matches
Mail list logo
