> 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 th
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 multip
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
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
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 is:
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
http://developer.postgresql.org/~pet
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 will
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:
http://www.postgresql.org/s
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:
http://www.postgresq
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 adhocke
> 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.
>
> -
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"
re
Ü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
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 ther
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
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 PageIndexMul
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 Con
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 surprise
Dear hackers,
I am migrating an application program
from Oracle to PostgreSQL, but one problem blocks me.
According to SQL92 standard, in
Oracle, identifiers that are not double quoted are changed to upper
case.
But, in PostgreSQL,
identifiers that are not double quoted are
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
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 develop
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
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 writ
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 hi
"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 pa
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
> 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.
>
Martijn van Oosterhout 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 come back 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 d
>> > 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 valu
On Wed, Jul 26, 2006 at 11:37:01AM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 of TIDs, sub
Martijn van Oosterhout 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 already with that pat
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.
R
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)
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-vacuu
> [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 h
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 restri
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
b
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 w
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 reo
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
> 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 adva
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:
kilo
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 t
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 that
"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 th
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 cor
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.
>
> T
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 do
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
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 t
Ü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
Ü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 s
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 actu
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 mult
Ü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.
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.
Bu
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 d
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 ab
Ü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 t
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.
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 Sl
Ü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
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 a
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?
T
> 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
>> equa
[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
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 try
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 wh
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,
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
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 w
On 7/26/06 10:14 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> 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
"Jie Zhang" <[EMAIL PROTECTED]> writes:
> On 7/26/06 10:14 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> ... A nonuniform distribution would probably mean that some
>> of the bitmaps compress better-than-expected and others worse. I have
>> no idea how to model that and guess what the overall resul
87 matches
Mail list logo
