Hi Heikki,
Finally i found some time to look more into the CRC code. The
time is mostly taken when there is a back-up block in the XLOG structure.
when it calculates the CRC for the entire block(there is some optimization
already for the holes), the time is spent on the CRC macro. I
Hi,
Currently The index implementation in Postgresql does not store the
Snapshot information in the Index. If we add the snapshot information into
the indexing structure, we will have the following advantages.
a) There can be index only scans like Oracle
b) Unique indexes will become less
Gokulakannan Somasundaram wrote:
Currently The index implementation in Postgresql does not store the
Snapshot information in the Index. If we add the snapshot information into
the indexing structure, we will have the following advantages.
This idea has been discussed to death many times
On Thu, Oct 04, 2007 at 05:33:43PM -0400, Tom Lane wrote:
This business with having libpq and ecpg pull in src/port modules
manually is getting unmaintainable. I wonder whether we could persuade
src/port to generate three versions of libpgport.a --- backend,
frontend, and frontend-shlib-ready
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
possible to have a kind of index-table ? We do have here some tables
which have 2-4
Csaba Nagy wrote:
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
possible to have a kind of index-table ? We do have here some
Gokulakannan Somasundaram wrote:
Finally i found some time to look more into the CRC code. The
time is mostly taken when there is a back-up block in the XLOG structure.
when it calculates the CRC for the entire block(there is some optimization
already for the holes), the time is
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
Currently The index implementation in Postgresql does not store the
Snapshot information in the Index. If we add the snapshot information
into
the indexing structure, we will have the following
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Csaba Nagy wrote:
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
Am Sonntag, 7. Oktober 2007 schrieb Gregory Stark:
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding
regardless,
It seems to me we aren't actually using strftime any
Am Samstag, 6. Oktober 2007 schrieb Tom Lane:
It's not real clear to me whether, on a Unix machine, there is even
supposed to be any difference between setting LC_TIME=es_ES.iso88591 and
setting it to es_ES.utf8. Since nl_langinfo(CODESET) is supposedly
determined only by LC_CTYPE, you could
Gokulakannan Somasundaram wrote:
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
IMO, the most promising approach to achieving index-only-scans at the
moment is the Dead Space Map, as discussed in the 8.3 dev cycle.
Index only scans means that in order to get certain results, we may
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
what should be returned for XML like emstrongPostgreSQL/strong
is a powerful, open source relational database system/em if user
requests for text under em node? In XML world, the correct answer is
PostgreSQL is a powerful, open
Ühel kenal päeval, E, 2007-10-08 kell 11:41, kirjutas Heikki
Linnakangas:
The dead space map holds
visibility information in a condensed form. For index-only-scans, we
need to know if all tuples on page are are visible to us. If the dead
space map is designed with index-only-scans in mind, we
Ühel kenal päeval, E, 2007-10-08 kell 12:12, kirjutas Gokulakannan
Somasundaram:
Hi,
Currently The index implementation in Postgresql does not store
the Snapshot information in the Index.
..
Please reply back with your comments.
I think you got enoght search for previous discussion
Peter Eisentraut wrote:
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
what should be returned for XML like emstrongPostgreSQL/strong
is a powerful, open source relational database system/em if user
requests for text under em node? In XML world, the correct answer is
On Mon, 2007-10-08 at 14:58 +0300, Hannu Krosing wrote:
1. get rid of indexes for TOAST tables
instead of TOAST tuple id store CTID of first TOAST block directly, and
use something like skip lists inside the TOAST block headers to access
next TOAST tuples.
It should be possible to optimise
Heikki Linnakangas [EMAIL PROTECTED] writes:
* mmap the WAL segments, instead of using the slru buffers.
This one's almost certainly a nonstarter, for lack of any portable way
to control when writes happen.
regards, tom lane
---(end of
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
* mmap the WAL segments, instead of using the slru buffers.
This one's almost certainly a nonstarter, for lack of any portable way
to control when writes happen.
For flushing, there's msync, which I believe is quite portable.
We
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
Log Message:
---
Added the Skytools extended transaction ID module to contrib as discussed
on CORE previously.
This module offers transaction ID's containing the original XID and the
transaction epoch as a bigint value to
Heikki Linnakangas [EMAIL PROTECTED] writes:
We mustn't write data pages before the WAL hits the disk, but we don't
have any such limitation for WAL.
Um, you're right, I was remembering discussions about trying to mmap
data files. Still, googling msync performance leaves me full of
concern
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
* mmap the WAL segments, instead of using the slru buffers.
This one's almost certainly a nonstarter, for lack of any portable way
to control when writes happen.
I think mlock and msync(MS_SYNC) ought to be
Magnus Hagander wrote:
Or I could've missed the discussion on -hackers that actually took place -
in that case, just discard this message. but the only one I recall is
someone asking for pl/proxy to go in.
There was some discussion (subject: Provide 8-byte transaction IDs to
user
Andrew Dunstan [EMAIL PROTECTED] writes:
I share your other concerns. This process certainly seems to have been
less than transparent.
FWIW, Jan asked -core about a week ago whether it'd be okay to add this
code post-beta, and we concluded it would be okay on the grounds that
(1) we've always
Hi Heikki,
I am always slightly late in understanding things. Let me try
to understand the use of DSM. It is a bitmap index on whether all the tuples
in a particular block is visible to all the backends, whether a particular
block contains tuples which are invisible to everyone. But i
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
Log Message:
---
Added the Skytools extended transaction ID module to contrib as discussed
on CORE previously.
To explain the situation, the public discussion about the
Marko Kreen wrote:
Now as you can read from recent disussion we had, we found out
that it would be *really* *really* cool if it would appear
in 8.3... Talk about last moment...
That discussion didn't happen on any list I read, so to me it just came
as a bolt from the blue.
Surely
Gokulakannan Somasundaram wrote:
Hi Heikki, I am always slightly late in understanding things. Let me
try to understand the use of DSM. It is a bitmap index on whether all
the tuples in a particular block is visible to all the backends,
whether a particular block contains tuples which are
Marko Kreen wrote:
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
Log Message:
---
Added the Skytools extended transaction ID module to contrib as discussed
on CORE previously.
To explain the situation, the public
Gokulakannan Somasundaram wrote:
I am always slightly late in understanding things. Let me try
to understand the use of DSM. It is a bitmap index on whether all the tuples
in a particular block is visible to all the backends, whether a particular
block contains tuples which are
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously Jan and Tom have
their own opinion.
Right. I can see your
Brendan Jurd wrote:
On 9/29/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I think we need more than one person's request to add this function.
Well, I don't expect it would get requested. Most DBAs would likely
look for the function in the docs, see it's not there and then just
implement it
Alvaro Herrera wrote:
Greg Smith wrote:
On Thu, 27 Sep 2007, Tom Lane wrote:
Also, I spent a dreary two or three hours this afternoon examining the
CVS commit logs since 8.3 branched...I tried to post that info to
pgsql-docs but it broke the list's message size limits (even
On 10/8/2007 1:34 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously Jan and Tom have
their
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
Log Message:
---
Added the Skytools extended transaction ID module to contrib as discussed
on
--- Original Message ---
From: Andrew Dunstan [EMAIL PROTECTED]
To: Marko Kreen [EMAIL PROTECTED]
Sent: 08/10/07, 18:05:57
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended
transactionID module to contrib as
Surely there should at the very least have been
Jan Wieck wrote:
On 10/8/2007 1:34 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously Jan
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously Jan and Tom have
their own opinion.
Alvaro Herrera wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
Not a whole lot of technical content there, but pretty interesting
nonetheless. I *think* that the issues we're seeing are largely in the
NFS
Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
Not a whole lot of technical content there, but pretty interesting
nonetheless. I *think* that the issues we're seeing are
Bruce Momjian escribió:
Brendan Jurd wrote:
On 9/29/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I think we need more than one person's request to add this function.
Well, I don't expect it would get requested. Most DBAs would likely
look for the function in the docs, see it's not
Magnus Hagander [EMAIL PROTECTED] writes:
The whole contrib thing confuses a lot of users. Is it included, or
isn't it? IMHO, that distinction need to be clear, and I thought we
were working (if not actively then at least passively) to retire
contrib, moving things either to core or to
On Mon, 2007-10-08 at 16:50 -0400, Alvaro Herrera wrote:
palloc uses malloc underneath. My thought is to replace that with
sbrk, mmap or something like that. Not very portable though, a lot of
work, and most likely not nearly enough benefits.
Yeah, I agree this isn't likely to be a win in
On Monday 08 October 2007 16:29, Magnus Hagander wrote:
The whole contrib thing confuses a lot of users. Is it included, or
isn't it? IMHO, that distinction need to be clear, and I thought we
were working (if not actively then at least passively) to retire
contrib, moving things either to
Tom Lane wrote:
(1) we've always been laxer about contrib than the core code,
While that appears to be true, I think
(a) there is no technical reason allowing us to do that, and
(b) most people don't seem to like it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Mon, 08 Oct 2007 17:38:48 -0400
Robert Treat [EMAIL PROTECTED] wrote:
On Monday 08 October 2007 16:29, Magnus Hagander wrote:
The whole contrib thing confuses a lot of users. Is it included, or
isn't it? IMHO, that distinction need to be clear, and I thought we
were working (if not
On Mon, 08 Oct 2007 22:32:55 +0200
Magnus Hagander [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my
Magnus Hagander [EMAIL PROTECTED] writes:
Right. My thought is still that if it isn't good enough for core, it
shouldn't be in contrib. If it *is* good enough, and we want it, we
should accept that it came in long after freeze and put it in core
anyway. If it *isn't*, then it should be on
A Dimarts 09 Octubre 2007, Joshua D. Drake va escriure:
Contrib is just a dead zone for the user populous. Most people consider
it unsupported *stuff* with no particular purpose (regardless of the
real meaning).
I think no visible documentation is the reason for this misconception and 8.3
Tom Lane wrote:
So I have no interest in trying to retire contrib. I think there's
room for debate about exactly which modules to include, of course.
I dont' think there's much call for retiring it. I think there is
interest in renaming it, as contrib is a wholly misleading
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
Log Message:
---
Added the Skytools extended transaction ID module to contrib as discussed
on CORE previously.
This module offers transaction ID's containing the original XID and the
transaction epoch as a bigint
Tatsuo Ishii wrote:
More question. Who is in charge of updating HISTORY? I see no commit
messages for this.
It is a generated file.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
More question. Who is in charge of updating HISTORY? I see no commit
messages for this.
It is a generated file.
I mean release.sgml.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
In hindsight, all these ecpg changes should have been made between beta1
and beta2 when we have time to deal with the fallout, not right before
beta1.
---
Tom Lane wrote:
This morning's ecpg patch certainly seems to have
Patch applied. Thanks. Your documentation changes can be viewed on our
web site shortly.
---
Brendan Jurd wrote:
On 10/4/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Now that we've
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that if you create a dump on a database containing a money
column and a certain locale, this dump is not restorable on a database
with a different locale.
We've been through this, no? If money doesn't print that way,
Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Asynchronous Commit allows some transactions to commit faster than
others, offering a trade-off between performance and durability for
specific transaction types only
A lot of users will be confused about what asynchronous
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that if you create a dump on a database containing a
money column and a certain
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
dering
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
dering money is deprecated, is this really needed?
We have other MONEY
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that if you create a dump on a database containing a
money column and a certain locale, this dump is not restorable on
a database with a
On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8
Hello,
The docs since 7.3 have declared the money type deprecated.. that is an
awful long time. Can we get some clarity on the issue?
If it isn't deprecated cool, I will submit a patch to docs.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
On Mon, 8 Oct 2007 20:02:56 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
-- Start of PGP signed section.
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED]
I had a thought a week ago. If we update the time zone database for
future dates, and you have a future date/time stored, doesn't the time
change when the time zone database changes.
For example if I schedule an appointment in New Zealand for 10:00a and
we change the time zone database so that
Tatsuo Ishii wrote:
More question. Who is in charge of updating HISTORY? I see no commit
messages for this.
It is a generated file.
I mean release.sgml.
Tom and others made commits to this and we will update it again before
final.
--
Bruce Momjian [EMAIL PROTECTED]
Tatsuo Ishii wrote:
More question. Who is in charge of updating HISTORY? I see no commit
messages for this.
It is a generated file.
I mean release.sgml.
Tom and others made commits to this and we will update it again before
final.
Did it? I see nothing for txid in
Tatsuo Ishii wrote:
Tatsuo Ishii wrote:
More question. Who is in charge of updating HISTORY? I see no commit
messages for this.
It is a generated file.
I mean release.sgml.
Tom and others made commits to this and we will update it again before
final.
Did it? I
Jan Wieck wrote:
On 10/8/2007 1:34 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously
Joshua D. Drake wrote:
The docs since 7.3 have declared the money type deprecated.. that is an
awful long time. Can we get some clarity on the issue?
IMHO it's not but it certainly need some more work on the storage
(numeric?) and locale part as already discussed.
--
Euler Taveira de
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after beta1.
regards, tom lane
---(end of
71 matches
Mail list logo
