Neil Conway wrote:
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to
use k for 1000, K for 1024, etc (mnemonic: upper case for the
larger multiplier).
Well, that only works for K vs. k: the SI prefix for mega is M
Hi -
I've searched the email archives, and the last I saw INSERT ... RETURNING
referenced was last March. I had two questions:
1) will this feature make it in 8.2?
2) is there a timeline for 8.2?
BTW, while searching for insert returning, I noticed an invalid hit (the url
goes to a different
I find those results moderately unconvincing, primarily because they
are based on choosing the least efficient possible data representation
(viz char(n)), and thus the btree indexes suffer severe and quite
artificial bloat. A database schema chosen with even minimal attention
The specific
On Tue, 2006-07-25 at 18:49 -0400, Tom Lane wrote:
One of the complaints I had about the bitmap index patch was the extent
to which it wants to modify (and largely create duplicate code paths in)
the existing executor support for bitmap scans. Now maybe I'm missing
something but I don't think
On Wed, 2006-07-26 at 08:12 +0200, Peter Eisentraut wrote:
Neil Conway wrote:
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to
use k for 1000, K for 1024, etc (mnemonic: upper case for the
larger multiplier).
Simon Riggs wrote:
don't ever need to say that K = 1000, AFAICS. I think we are safe to
assume that
kB = KB = kb = Kb = 1024 bytes
mB = MB = mb = Mb = 1024 * 1024 bytes
gB = GB = gb = Gb = 1024 * 1024 * 1024 bytes
There's no value in forcing the use of specific case
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I'll take a whack at that patch this evening PDT or tomorrow evening
at the latest. We're too late in the cycle to go over this, but maybe
we can figure out a way to have this data read from
Bruce Momjian wrote:
Tom Lane wrote:
Joshua Reich [EMAIL PROTECTED] writes:
The problem is that there are new functions in cube.sql, so the output
is now different and breaks the diff (to state the obvious).
Actually, the new theory on this is that you should explicitly create
a shell type
Hi,
I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.
- predefined variable tps
The value of variable tps is taken from the scaling factor
specified by -s option.
- -D option
Variable values can be defined by -D option.
- \set command now
SIGFPE is a synchornous signal and Windows will raise it if proper flag is
set (check out the example program):
http://msdn2.microsoft.com/en-us/library/kfy34skx.aspx
But seems we didn't use the above method. Instead, we use the same
methodology as other asynchrounous signals. My question
Simon Riggs wrote:
There's no value in forcing the use of specific case and it will be
just confusing for people.
The issue was not the case of the units, but people were suggesting that
we should enforce the use of kiB, MiB, and GiB.
--
Peter Eisentraut
I heard that 2 security bugs were fixed in 8.1.4.
Since I like to upgrade from 8.1.3, I like to know the bugs.
Can somebody give the description of those bugs?
Thanks
Dhanaraj
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
Tom Lane wrote:
That seems OK for SHOW, which is mainly intended for human
consumption, but what will you do with pg_settings? For programmatic
use I think we want more predictable behavior.
I'd think that a program would not care. Or do you want a units-free
display that can be parsed as
On Jul 26, 2006, at 19:17 , Dhanaraj M wrote:
I heard that 2 security bugs were fixed in 8.1.4.
Since I like to upgrade from 8.1.3, I like to know the bugs.
Can somebody give the description of those bugs?
Following the Security link from the Postgres home page:
Quoting Greg Stark [EMAIL PROTECTED]:
Tom Lane [EMAIL PROTECTED] writes:
I'm fairly dissatisfied with the naming of Greg Stark's proposed new
feature for creating indexes without blocking writers of the table.
To my mind, ONLINE just doesn't convey any useful information ---
the existing
Dhanaraj M wrote:
I heard that 2 security bugs were fixed in 8.1.4.
Since I like to upgrade from 8.1.3, I like to know the bugs.
Can somebody give the description of those bugs?
There is a list of the changes in each release in the Release Notes. In
this case, you want:
Quoting Simon Riggs [EMAIL PROTECTED]:
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous
I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.
- predefined variable tps
The value of variable tps is taken from the scaling factor
specified by -s option.
- -D option
Variable values can be defined by -D option.
- \set command
I understand the negative implications with calling it ONLINE with regards
to the index rebuild but I believe that would follow what the industry and
professionals understand. Oracle denotes this concept as ONLINE and
microsoft with it's new SQL Server 2005 markets the ability to do ONLINE
Ühel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost full
acess to the table allowed but their syntax does not use the word online.
Does this reorganizing refer to what we do with CLUSTER ?
I'd really love
On 7/26/06, craigp [EMAIL PROTECTED] wrote:
1) will this feature make it in 8.2?
2) is there a timeline for 8.2?
Unless someone else picks it up, it won't make it. I had updated
Omar's patch to the 8.2 codebase and submitted it to -patches. While
working on it a bit later, I found that there
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
That seems OK for SHOW, which is mainly intended for human
consumption, but what will you do with pg_settings? For programmatic
use I think we want more predictable behavior.
I'd think that a program would not care. Or do you want
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
The problem is that we've traded splitting a page every few hundred
inserts for doing a PageIndexMultiDelete, and emitting an extra WAL
record, on *every* insert. This is not good.
I suspect PageIndexMultiDelete()
I'm not sure about how the xlogdump should behave when translating oids of dropped relations.Now I'm just showing the oid, and ignoring the translation in these cases.But may be it's a good idea to giva a hint to the user (printing dropped).
Any advices?-- Diogo Biazus - [EMAIL PROTECTED]Móvel
I wrote:
... A realistic assumption for the numbers you mention is
that the bitmaps have 1-bits about 100 bits apart, which means you
could get maybe 3-to-1 compression using the runlength scheme that's
in there ... leaving the bitmap a factor of 20 bigger than the btree.
I'm surprised no
Dear hackers,
I am migrating an application program
fromOracle to PostgreSQL, but one problem blocks me.
According to SQL92 standard, in
Oracle, identifiersthat are not double quoted are changed to upper
case.
But, in PostgreSQL,
identifiersthat are not double quoted are changed to
Peter Eisentraut [EMAIL PROTECTED] writes:
Greg Stark wrote:
One thing to think about, what will the command to execute stored
procedures look like? Those will also need to be called from outside
a transaction.
Huh? Only if you invent your own stored-procedure theory or have a
Tom Lane [EMAIL PROTECTED] writes:
This patch is nowhere near ready for submission :-(. Most of the
comments seem to be I don't know what to do here ...
Just to be clear, I think what Tom's saying it's not ready to be *applied*.
Sending patches to this list early and often during development
Tatsuo Ishii [EMAIL PROTECTED] writes:
BTW, running long benchmark using pgbench on BIG tables easily causes
an integer overflow error in following SQLs:
Right.
I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?
No. The problem is that the
Paul Silveira [EMAIL PROTECTED] writes:
If I didn't know anything about PostgreSQL and read a manual about it's
indexing capabilities and read that it had ONLINE reindexing, the first
thing that I would think about was the ability to rebuild my indexes without
causing any blocking or writers
Tom Lane [EMAIL PROTECTED] writes:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea
Diogo Biazus [EMAIL PROTECTED] writes:
I'm not sure about how the xlogdump should behave when translating oids of
dropped relations.
I'm not sure it should be making any attempt to translate anything.
What makes you think the oids even refer to the current database?
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
This patch is nowhere near ready for submission :-(. Most of the
comments seem to be I don't know what to do here ...
Just to be clear, I think what Tom's saying it's not ready to be *applied*.
Sending patches to
On Tue, Jul 25, 2006 at 06:49:02PM -0400, Tom Lane wrote:
What if we dropped the array convention, and simply passed the tidbitmap
object to the index AM's getmulti function, with the instructions stuff
all the TIDs into this bitmap, and don't come back till you're done?
For the existing index
Hi,
I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.
- predefined variable tps
The value of variable tps is taken from the scaling factor
specified by -s option.
- -D option
Variable values can be defined by -D option.
- \set
Martijn van Oosterhout kleptog@svana.org writes:
On Tue, Jul 25, 2006 at 06:49:02PM -0400, Tom Lane wrote:
What if we dropped the array convention, and simply passed the tidbitmap
object to the index AM's getmulti function, with the instructions stuff
all the TIDs into this bitmap, and don't
Hi,
I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.
- predefined variable tps
The value of variable tps is taken from the scaling factor
specified by -s option.
- -D option
Variable values can be defined by -D option.
Hi,
I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.
- predefined variable tps
The value of variable tps is taken from the scaling factor
specified by -s option.
- -D option
Variable values can be defined by -D option.
On Wed, Jul 26, 2006 at 11:37:01AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Well, my only thoughtis that this pretty means you can't use
index_getmulti for anything else. For example, when I was playing with
async i/o I was using index_getmulti to get a list
Martijn van Oosterhout kleptog@svana.org writes:
I've considered whether it's worthwhile going to other way: getting the
IndexScan executer node to uses getmulti to reduce index AM overhead.
But that requires backward scan support also...
I think Heikki got most of the low-hanging fruit
Gregory Start wrote:
Fwiw a few data points:
MSSQL uses (WITH ONLINE=ON) much like we and Oracle use ONLINE tacked
on to the
end of the create index command.
Where did you find this? I thought my MSDN-foo was pretty good, and I
didn't find this when searched a couple days ago.
Peter Eisentraut wrote:
I'd imagine that one of the first things someone will want to try is
something like SET work_mem TO '10MB', which will fail or misbehave
because 1000 bytes do not divide up into chunks of 1024
bytes. Who
wants to explain to users that they have to write
Bort, Paul wrote:
The Linux kernel changed to the standard years ago. And that's just a
few more lines of code than PostgreSQL. (
http://kerneltrap.org/node/340 and others )
For your entertainment, here are the usage numbers from the linux-2.6.17
kernel:
kilobyte (-i) 82
kibibyte (-i) 2
Gregory Stark [EMAIL PROTECTED] writes:
... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point here is
that the existing vacuum does not rely on re-computing index keys; all
it cares about is matching TIDs. The retail-vacuum
[snip] (In fact, it's
trivial to see how user-defined functions that are mislabeled immutable
could make this fail.) So retail vacuum without any cross-check that
you got all the index tuples is a scary proposition IMHO.
Wouldn't work to restrict that kind of vacuum to only tables which have
Csaba Nagy [EMAIL PROTECTED] writes:
[snip] (In fact, it's
trivial to see how user-defined functions that are mislabeled immutable
could make this fail.) So retail vacuum without any cross-check that
you got all the index tuples is a scary proposition IMHO.
Wouldn't work to restrict that
Tom Lane [EMAIL PROTECTED] writes:
So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.
Well the desire for it comes from a very well established need for dealing
with extremely large tales with relatively small hot spots. The basic problem
Hiroshi Saito wrote:
From: Andrew Dunstan
Hiroshi Saito wrote:
Hmm, It seems to be the bug of very unpleasant Microsoft.:D
I think that the following is desirable as an evasion measure to add.
#if defined(_MSC_VER) _MSC_VER == 1400
To be sure, it was only VS2005.
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost full
acess to the table allowed but their syntax does not use the word online.
Does this reorganizing
Peter Eisentraut politely corrected:
For your entertainment, here are the usage numbers from the
linux-2.6.17
kernel:
kilobyte (-i) 82
kibibyte (-i) 2
megabyte (-i) 98
mebibyte (-i) 0
gigabyte (-i) 32
gibibyte (-i) 0
KB1151
kB407
KiB 181
MB
I am a PostgreSQL lover at China, I'd like to know when the column-level
privilege can be added to a release version of PostgreSQL? and is there
someone who is working on the problem?
You can often achieve similar effects with VIEWs and RULEs / TRIGGERs.
Drew
Is this an appropriate place for questions about implementing user
defined functions and custom data types in the C programming language?
I didn't want to dirty the general user list with these types of
questions, but I thought I'd better ask before I posted a question
here.
I apologize in
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
---
Marko Kreen wrote:
Intro
Peter Eisentraut wrote:
Bort, Paul wrote:
The Linux kernel changed to the standard years ago. And that's just a
few more lines of code than PostgreSQL. (
http://kerneltrap.org/node/340 and others )
For your entertainment, here are the usage numbers from the linux-2.6.17
kernel:
On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote:
Diogo Biazus [EMAIL PROTECTED] writes: I'm not sure about how the xlogdump should behave when translating oids of dropped relations.I'm not sure it should be making any attempt to translate anything.
What makes you think the oids even refer to the
On Wed, Jul 26, 2006 at 12:17:00PM -0400, Bort, Paul wrote:
Peter Eisentraut wrote:
I'd imagine that one of the first things someone will want to try is
something like SET work_mem TO '10MB', which will fail or misbehave
because 1000 bytes do not divide up into chunks of 1024
Folks
I'm glad to be back on the pgsql-hackers mailing list. I'm writing to give
an update on the status of TelegraphCQ.
As Josh says, the TelegraphCQ project at UC Berkeley is more or less done as
most of the students on the project have graduated, or will be done this
summer.
Having said
Diogo Biazus [EMAIL PROTECTED] writes:
On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote:
I'm not sure it should be making any attempt to translate anything.
What makes you think the oids even refer to the current database?
I'm getting a new database connection based on the dbNode of the current
Bruce Momjian [EMAIL PROTECTED] writes:
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
The part of this that would actually be useful to put in core is
On Wednesday 26 July 2006 13:04, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
The part of
Susanne Ebrecht [EMAIL PROTECTED] writes:
here is a patch that extends update syntax following the sql standard.
The patch includes sgml documentation, too.
UPDATE table SET (col1, col2, ...) = (val1, val2, ...),
(colm, coln, ...) = (valm, valn, ...), ...;
This is a cute hack, but it does
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.
Well the desire for it comes from a very well established need for dealing
with extremely
Darcy Buskermolen [EMAIL PROTECTED] writes:
The question though is if we did that, would Slony actually use it?
If it made sence to do it, then yes we would do it. The problem ends up being
Slony is designed to work across a multitude of versions of PG, and unless
this was backported to at
Ühel kenal päeval, K, 2006-07-26 kell 13:41, kirjutas Darcy Buskermolen:
On Wednesday 26 July 2006 13:04, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such
Ühel kenal päeval, K, 2006-07-26 kell 13:35, kirjutas Bruce Momjian:
I am sure you worked hard on this, but I don't see the use case,
The use case is any slony-like replication system or queueing system
which needs consistent means of knowing batches of transactions which
have finished during
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
The part of this that would actually be
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
The question though is if we did that, would Slony actually use it?
If it made sence to do it, then yes we would do it. The problem ends up
being Slony is designed to work across a multitude of
Ühel kenal päeval, K, 2006-07-26 kell 23:02, kirjutas Martijn van
Oosterhout:
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.
Well
Martijn van Oosterhout wrote:
How about this:
INFO: Your setting was converted to IEC standard binary
units. Use KiB,
MiB, and GiB to avoid this warning.
That's silly. If you're going to treat KB as 1024 bytes anyway,
complaining about it is just being pedantic.
But after a
On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote:
Diogo Biazus [EMAIL PROTECTED] writes: On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote: I'm not sure it should be making any attempt to translate anything.
What makes you think the oids even refer to the current database? I'm getting a new database
Yeah, your probably right. :)
On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote:
Paul Silveira [EMAIL PROTECTED] writes: If I didn't know anything about PostgreSQL and read a manual about it's
indexing capabilities and read that it had ONLINE reindexing, the first thing that I would think about was
Ühel kenal päeval, K, 2006-07-26 kell 13:23, kirjutas Gregory Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost
full
acess to the table
Alvaro Herrera wrote:
Darcy Buskermolen wrote:
I'll take a bit more of a look through the patch and see if it is a real boot
to use it on those platforms that support it, and that we have a suitable way
around it on those that don't. But at this point I wouldn't hold my breath
on that
Tatsuo Ishii [EMAIL PROTECTED] writes:
BTW, running long benchmark using pgbench on BIG tables easily causes
an integer overflow error in following SQLs:
Right.
I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?
No. The problem is
Darcy Buskermolen wrote:
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
The question though is if we did that, would Slony actually use it?
If it made sence to do it, then yes we would do it. The problem ends up
being Slony is designed
Ühel kenal päeval, K, 2006-07-26 kell 14:27, kirjutas Darcy Buskermolen:
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
The question though is if we did that, would Slony actually use it?
If it made sence to do it, then yes we would do it.
On Jul 27, 2006, at 6:10 , Martijn van Oosterhout wrote:
The thing is, most memory sizes in postgres need to be some
multiple of
a page size. You can't have a shared buffers of exactly 10 bytes,
while 102400 bytes is possible.
I've seen this mentioned a couple of times. I'm not nearly
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on an undefined symbol?
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on an undefined symbol?
[EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on
From: Florian G. Pflug
Ahhh, It is right.!
I was retracing my memory for what situations the contents were.
I was in distraction.It seems that it is satisfactory at the reason for ==.
Sorry and Thanks.!!
Regards,
Hiroshi Saito
Bruce Momjian wrote:
Why is this better than:
#if
jkzhao [EMAIL PROTECTED] wrote
But, create user HU then connect PostgreSQL by HU is wrong.
If you do
postgres=# create user HU;
You will get the HU as you want. Usage of the quotation marks is in the
manual.
I'd like to know whether I can make PostgreSQL stands to the SQL92
Tom Lane wrote:
I'm surprised no one caught me making this bogus computation. I
realized this morning it's wrong: if there are 1 distinct values
then on the average the 1-bits would be about 1 bits apart, not 100.
Right - I didn't think 1 was *that* bad, but was too sleepy to
Tom,
On 7/26/06 7:26 AM, Tom Lane [EMAIL PROTECTED] wrote:
I wonder
whether they oughtn't use 16-bit instead of 8-bit HRL_WORDs
We tried variations from 8-bit to 32-bit and came to the conclusion that
8-bit was a better match for the more general case. For the moment I forget
exactly why
Michael Glaesemann [EMAIL PROTECTED] writes:
I've seen this mentioned a couple of times. I'm not nearly as
familiar with these settings as I should be, but it seems to me that
if the memory size *does* need to be a integral multiple of page
size, e.g., n * page_size = memory_size, why
On 7/26/06 8:55 PM, Luke Lonergan [EMAIL PROTECTED] wrote:
Tom,
On 7/26/06 7:26 AM, Tom Lane [EMAIL PROTECTED] wrote:
I wonder
whether they oughtn't use 16-bit instead of 8-bit HRL_WORDs
We tried variations from 8-bit to 32-bit and came to the conclusion that
8-bit was a better match
Mark Kirkwood [EMAIL PROTECTED] writes:
An obvious deduction is that the TPCH dataset is much more amenable to
run compression than my synthetic Zipfian data was. The interesting
question is how well real datasets are run compressable,
Yeah --- the back-of-the-envelope calculations I was
87 matches
Mail list logo
