David E. Wheeler da...@kineticode.com writes:
On Dec 9, 2010, at 12:34 PM, Dimitri Fontaine wrote:
- add support for 'relocatable' boolean property in the control file,
as discussed on list
This still isn't ideal, but I think it's a big improvement. Thanks.
Glad you like it :) If you see
On Fri, Dec 10, 2010 at 3:51 PM, aaliya zarrin aaliya.zar...@gmail.com wrote:
Can anybody tell after finding the trigger file what steps does postgres
follow?
The server applies all the WAL records available, performs checkpoint,
renames recovery.conf, and gets out of recovery mode.
Regards,
On 12/09/2010 03:36 PM, BRUSSER Michael wrote:
No, we do not use --with-system-tzdata option.
I looked at the makefile and at the output of pg_config. We may need to do
some cleanup there, but I did not pick any clues.
The problem occurs on all our UNIX platforms.
Is there anything I could
Hi ,
I want to stop the recovery forcefully what shall I do? Rather say,
after finding the trigger file I want postgres to switch over?
Which function shall I call?
Where the flow is transfer exactly after finding the trigger file?
On Fri, Dec 10, 2010 at 2:36 PM, Fujii Masao
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael
michael.brus...@3ds.com wrote:
- initdb:
initdb -D /home/local_path/pgdata -L /home/local_path/share -E UTF8
--locale=C \
-d 2 log2 log1
log1 ends with line
creating template1 database in /home/local_path/pgdata/base/1 ...
In
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
On 12/10/2010 07:32 AM, Robert Haas wrote:
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael
michael.brus...@3ds.com wrote:
- initdb:
initdb -D /home/local_path/pgdata -L /home/local_path/share -E UTF8
--locale=C \
-d 2 log2 log1
log1 ends with line
creating template1 database
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
Ideally, the clock sweep would be run by bgwriter and not individual
backends. In that case it shouldn't matter much what the performance of the
sweep is. To do that I think we'd want the bgwriter to target there being X
In log2 I got the same errors as I mentioned earlier:
LOG: could not open directory /home/build-path/.../share/timezone: No
such file or directory
... ...
Does it really have a pathname with three dots here?
I'd have more confidence we knew what we were looking at if you sent
the
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael
michael.brus...@3ds.com wrote:
1) The pathnames referenced in the log do not have any dots, I just truncated
them -
they are absolute pathnames to where the timezone files are locates in
the source or build tree
I'll post the entire
Dan Ports wrote:
On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
The only thing I'm worried about here is how much risk of
starvation remains. You'd need to wait until there are no running
r/w transactions accessing overlapping data sets; for some
applications that might
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
Ideally, the clock sweep would be run by bgwriter and not individual
backends. In that case it shouldn't matter much what the performance of
On 12/10/2010 09:55 AM, Robert Haas wrote:
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael
michael.brus...@3ds.com wrote:
1) The pathnames referenced in the log do not have any dots, I just truncated
them -
they are absolute pathnames to where the timezone files are locates in the
Well, why are you configuring the prefix to be inside your build tree?
This is an odd thing to do. The prefix should be set to where you
expect to install the files, not where you're building them.
CONFIGURE = '--prefix=/home/build-path/build/Linux/qe_x86_64'
'--without-readline'
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
David E. Wheeler da...@kineticode.com writes:
What if $extension.control exists? Is it a byproduct of the .in file
from previous `make` run or a user file? What if we have both the .in
and the make variable because people are confused? Or both
Tom Lane t...@sss.pgh.pa.us writes:
Are there any actual remaining use-cases for that sed step?
The goal here is to allow extension authors to maintain their version
number in the Makefile rather than in the Makefile and in the control
file separately. Having the same version number in more than
On 12/10/2010 10:25 AM, Andrew Dunstan wrote:
Not claiming any knowledge in this area - would it be
reasonable to expect that if -L option works for other input files
it should
also work for timezones?
...this seems reasonable.
OK, this has nothing at all to do with the
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan and...@dunslane.net wrote:
Here's my understanding.
It's not initdb that's really complaining. The timezone files are not inputs
to initdb. It's the postgres that initdb invokes that's complaining.
That was my impression, too, from the log that
On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
[ message that was forwarded to three mailing lists in an 12 hour period ]
Come on, give me a break! How quickly do you expect people to answer
your questions? It's reasonable to follow up if you haven't heart
anything
Robert Haas robertmh...@gmail.com writes:
So in theory we could have a GUC under file locations to override
this, similarly to data_directory or hba_file or ident_file. But
since it's been like this for a really long time (I think), I wouldn't
be inclined to go monkeying with it unless more
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Are there any actual remaining use-cases for that sed step?
The goal here is to allow extension authors to maintain their version
number in the Makefile rather than in the Makefile and in the control
file
Tom Lane t...@sss.pgh.pa.us writes:
Why is it in the makefile at all? If the makefile does need to know it,
why don't we have it scrape the number out of the control file? Or even
more to the point, since when do we need version numbers in extensions?
It's in the Makefile so that you find it
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
To do that I think we'd want the bgwriter to target there being X
Hey Robert,
2010/12/10 Robert Haas robertmh...@gmail.com
On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
[ message that was forwarded to three mailing lists in an 12 hour period
]
Come on, give me a break!
Please sorry ! But I don't mail to you personally.
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
As far as I can tell, bgwriter never adds things to the freelist.
That is only done at start up, and when a relation or a database is
dropped. The clock sweep does the vast
Dmitriy Igrishin wrote:
Where is it written ?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hey Kevin,
Oh, I am sorry! Thanks!
2010/12/10 Kevin Grittner kevin.gritt...@wicourts.gov
Dmitriy Igrishin wrote:
Where is it written ?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
-Kevin
--
// Dmitriy.
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Why is it in the makefile at all? If the makefile does need to know it,
why don't we have it scrape the number out of the control file? Or even
more to the point, since when do we need version numbers in
On Dec 10, 2010, at 12:26 AM, Dimitri Fontaine wrote:
What if $extension.control exists? Is it a byproduct of the .in file
from previous `make` run or a user file? What if we have both the .in
and the make variable because people are confused? Or both the make
variables and a .control and not
On Dec 10, 2010, at 7:32 AM, Tom Lane wrote:
Are there any actual remaining use-cases for that sed step? It's
certainly vestigial as far as the contrib modules are concerned:
it would be simpler and more readable to replace MODULE_PATHNAME with
$libdir in the sources. Unless somebody can
2010/12/10 Tom Lane t...@sss.pgh.pa.us:
I wrote:
We're throwing away one tuple at a time as we advance forward through
the tuplestore, and moving 10+ tuple pointers each time. Ugh.
This code was all right when written, because (IIRC) the mergejoin
case was actually the only caller. But
Hitoshi Harada umi.tan...@gmail.com writes:
I see it's too late now that you've committed it,
Patches can always be reverted...
but it seems there
was another way to avoid it by not trimming from percent_rank()
individually. Once the whole partition is fit to the memory, you don't
need to
On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
It would be quicker to answer my question and help than to teach me
the alphabet of communication. Although, thank you, and for that :-)
It would be quicker still to ignore your email altogether, but I'm
guessing you're
2010/12/11 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
I see it's too late now that you've committed it,
Patches can always be reverted...
but it seems there
was another way to avoid it by not trimming from percent_rank()
individually. Once the whole partition
3. Shutdown should abort all the blocking transactions?
* Problem is that a client thinks that those transactions have been
aborted
even though those WAL records have been written on the master. But
this is very common problem for DBMS, so we don't need to worry about
On Thu, Dec 09, 2010 at 09:48:25AM +, Simon Riggs wrote:
On Fri, 2010-12-03 at 21:43 +0200, Heikki Linnakangas wrote:
On 29.11.2010 08:10, Noah Misch wrote:
I have a hot_standby system and use it to bear the load of various
reporting
queries that take 15-60 minutes each. In an
2010/12/10 Robert Haas robertmh...@gmail.com
On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
It would be quicker to answer my question and help than to teach me
the alphabet of communication. Although, thank you, and for that :-)
It would be quicker still to
On 12/10/2010 11:19 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
So in theory we could have a GUC under file locations to override
this, similarly to data_directory or hba_file or ident_file. But
since it's been like this for a really long time (I think), I wouldn't
be
Hitoshi Harada umi.tan...@gmail.com writes:
Hm? Once percent_rank() scans to the partition end, any other window
functions that scans row by row don't need to care the memory
reduction, aren't they? Or more generally, if the partition was
scanned to the end, we don't need to trim tuplestore
On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not convinced that this is actually a requirement, or that doing it
this specific way is a good solution. In particular, keeping the
version number in the system catalogs seems pretty dubious. The common
method for
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... In particular, keeping the
version number in the system catalogs seems pretty dubious. The common
method for upgrading an already-installed contrib module just involves
dropping
On Dec 10, 2010, at 10:20 AM, Tom Lane wrote:
True. Consider a situation like an RPM upgrade: it's going to drop in a
new .so version, *and nothing else*. It's pure fantasy to imagine that
the RPM script is going to find all your databases and execute some SQL
commands against them. Since
Tom Lane t...@sss.pgh.pa.us writes:
This doesn't answer my question of why it couldn't be done the other
way. Why does the makefile need to know it? If it does need to know
it, couldn't it get it out of the control file instead of vice versa?
Well the Makefile support is just a facility to
On 12/10/2010 11:19 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
So in theory we could have a GUC under file locations to override
this, similarly to data_directory or hba_file or ident_file. But
since it's been like this for a really long time (I think), I wouldn't
be
On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
Well the Makefile support is just a facility to fill in the control file
automatically for you, on the grounds that you're probably already
maintaining your version number in the Makefile. Or that it's easy to
get it there, as in:
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
Upgrade are left for a future patch, did we decide. Still, it seems to
me that we will support some upgrade scripts so that author can decide
what to do knowing current and next version, and
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
This doesn't answer my question of why it couldn't be done the other
way. Why does the makefile need to know it? If it does need to know
it, couldn't it get it out of the control file instead of vice versa?
On Dec 10, 2010, at 11:47 AM, Tom Lane wrote:
Why would you choose to maintain it in the Makefile? In most cases
makefiles are the least likely thing to be changing during a minor
update. I would think that the right place for it is in the C code
(if we're trying to version .so files) or
Tom Lane t...@sss.pgh.pa.us writes:
Why would you choose to maintain it in the Makefile? In most cases
makefiles are the least likely thing to be changing during a minor
update.
I must have a packager skewed view of things here, but ok, point noted.
I would think that the right place for
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
disk.
The fact that it's called md.c is a hangover from the '80s. These days,
the
On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
Or do we want contrib's specific version numbers that are not all the
same as the current PostgreSQL version number?
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Also, once
I'm finally getting around to something that's been on my todo list for
a couple of months.
I wrote:
Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
handled *exactly* the way that the -D target
On 12/04/2010 11:11 PM, Itagaki Takahiro wrote:
On Sun, Dec 5, 2010 at 07:24, Andrew Dunstanand...@dunslane.net wrote:
Looking at file_parser.c, it seems to be largely taken from copy.c. Wouldn't
it be better to call those functions, or refactor them so they are callable
if necessary?
We
Josh Berkus j...@agliodbs.com writes:
On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
Or do we want contrib's specific version numbers that are not all the
same as the current PostgreSQL version number?
I think that each contrib needs its own version numbers. The reason
being that most minor
Josh Berkus j...@agliodbs.com writes:
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Fair enough. What are the version numbers of each current contribs?
Also, once extensions and pgxn are operating full swing, I see
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite skeptical about it. Quite
apart from anything else we should keep enough extensions in core to
test the
On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite skeptical about it. Quite
apart from anything
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
On to your question about the upgrade design, in order not to paint
ourselves into a corner. What I now have in mind is the following:
When there's an extension upgrade the user will have to install the new
files (.so, .sql, .control) and run an
Joshua D. Drake j...@commandprompt.com writes:
On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite
Tom Lane t...@sss.pgh.pa.us writes:
I don't believe that extension SQL scripts should rely on DO blocks.
There is no requirement that plpgsql be installed, and we're not going
to create one as part of this feature. What this means is that the
design you offer above doesn't work at all, since
On 12/10/10 12:34 PM, Dimitri Fontaine wrote:
Josh Berkus j...@agliodbs.com writes:
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Fair enough. What are the version numbers of each current contribs?
I'd say that for
Josh Berkus j...@agliodbs.com writes:
The alternative would be to match postgresql minor version numbering
exactly, and then come up with some way to have a no-op upgrade in the
frequent cases where the contrib module isn't changed during a minor
release. This would also require some kind of
On Fri, Dec 10, 2010 at 4:50 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Now, what about having the control file host an 'upgrade' property where
to put the script name? We would have to support a way for this filename
to depend on the already installed version, I'm thinking that %v
On Fri, Dec 10, 2010 at 12:21 PM, Daniel Loureiro loureir...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
disk.
On Dec 10, 2010, at 1:55 PM, Josh Berkus wrote:
I'd say that for anything in /contrib, it gets a new version with each
major version of postgresql, but not with each minor version. Thus,
say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
fix a bug in dblink, then it
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
(Actually, we could probably assume that the target version is
implicitly the current version, as identified from the control file,
and omit that from the script file names. That would avoid ambiguity
if version numbers can have more than
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
I don't think we can safely design around one part version numbers here,
because I'm yet to see that happening in any extension I've had my hands
on, which means a few already, as you can
On Dec 10, 2010, at 2:32 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
I don't think we can safely design around one part version numbers here,
because I'm yet to see that happening in any extension I've had my
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
(Actually, we could probably assume that the target version is
implicitly the current version, as identified from the control file,
and omit that from the script file names. That would avoid
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible* to do more
complicated things, but don't *require* it.
Josh Berkus j...@agliodbs.com writes:
I'd say that for anything in /contrib, it gets a new version with each
major version of postgresql, but not with each minor version. Thus,
say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
fix a bug in dblink, then it becomes dblink
On Dec 10, 2010, at 2:40 PM, Tom Lane wrote:
Since you know the existing version number, you just run all that come
after. For example, if the current version is 1.12, then you know to run
foo-1.13.sql and foo-1.15.sql.
If we assume the target is the current version, then we only need the
Jeff Janes jeff.ja...@gmail.com writes:
Of course if you do a full table scan because their are no better
options, then it scans sequentially. But you have to scan the pages
in *some* order, and it is hard to see how something other than
sequential would be systematically better.
In fact, if
On Dec 10, 2010, at 2:43 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible*
On Fri, Dec 10, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm finally getting around to something that's been on my todo list for
a couple of months.
I wrote:
Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
the creation and properties of
Tom Lane t...@sss.pgh.pa.us writes:
If we assume the target is the current version, then we only need the
old-version number in the file name, so it doesn't matter how many
parts it has.
IIUC, that puts even more work on the shoulders of the extension
authors, because the file named
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible* to do
On Dec 10, 2010, at 2:55 PM, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
If we assume the target is the current version, then we only need the
old-version number in the file name, so it doesn't matter how many
parts it has.
IIUC, that puts even more work on the shoulders of
On Dec 10, 2010, at 2:58 PM, Tom Lane wrote:
Maybe I misread David's meaning, but I thought he was saying that
there's no value in inventing all those control file entries in the
first place. Just hard-wire in ALTER EXTENSION UPGRADE the convention
that the name of an upgrade script to
Robert Haas robertmh...@gmail.com writes:
+1 for src/port.
...
At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
regards, tom lane
--
Sent via pgsql-hackers mailing list
David E. Wheeler da...@kineticode.com writes:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts are
handled: version-string-named directories with the appropriate scripts to
upgrade *to* the named version number.
But you still have to know what you're upgrading
I believe that PostgreSQL was been developed and optimized for
sequential access. To get full advantage of SSDs its necessary to
rewrite almost the whole project - there are so much code written with
the sequential mechanism in mind.
You can believe whatever you want, that doesn't make it
On 12/10/2010 06:01 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
+1 for src/port.
...
At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
I think this is
Hello hackers,
I think i'm at the right place to ask this question.
Based on your experience and the fact that you have written the Postgres code,
can you tell what a rough break-down - in your opinion - is for the time the
database spends time just fetching and writing stuff to memory and
On Fri, 2010-12-10 at 15:08 -0800, Josh Berkus wrote:
I believe that PostgreSQL was been developed and optimized for
sequential access. To get full advantage of SSDs its necessary to
rewrite almost the whole project - there are so much code written with
the sequential mechanism in mind.
On Fri, Dec 10, 2010 at 6:08 PM, Josh Berkus j...@agliodbs.com wrote:
Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
which is an in-memory database. Even for a pure-RAM database, it turns
out that just using linked lists and 100% random access is slower than
accessing
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Hamza Bin Sohail
Sent: Friday, December 10, 2010 3:10 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] would hw acceleration help postgres (databases in
On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
are handled: version-string-named directories with the appropriate scripts
to upgrade *to* the named version number.
But you still have to know what you're upgrading
Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
which is an in-memory database. Even for a pure-RAM database, it turns
out that just using linked lists and 100% random access is slower than
accessing page images.
That's a slightly different problem, though.
On Fri, Dec 10, 2010 at 3:13 PM, Joshua D. Drake j...@commandprompt.com wrote:
Actually, the only (that I know of) optimized for sequential access code
we have would be for the xlogs.
And even that is more of a book-keeping simplification, rather than an
optimization.
You have to know where
On 10.12.2010 21:21, Daniel Loureiro wrote:
The fact that it's called md.c is a hangover from the '80s. These days,
the logic that the Berkeley guys envisioned being at that code level
is generally in kernel device drivers. md.c can drive anything that
behaves as a block device + filesystem,
On 12/10/10 3:09 PM, Hamza Bin Sohail wrote:
There is not much utility in doing this if there aren't considerable compute-
intensive operations in the database (which i would be surprise if true ). I
would suspect joins, complex queries etc may be very compute-intensive.
Please
correct me
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
are handled: version-string-named directories with the appropriate scripts
to upgrade *to* the named version number.
But you
On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
Huh? It's in the pg_extension catalog.
How do you select which upgrade script to apply?
You run all those that contain version numbers higher than the
currently-installed one.
This of course assumes that one can correctly tell that one version
On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail hsoh...@purdue.edu wrote:
Hello hackers,
I think i'm at the right place to ask this question.
Based on your experience and the fact that you have written the Postgres code,
can you tell what a rough break-down - in your opinion - is for the
2010/12/8 Kineticode Billing da...@kineticode.com:
On Dec 8, 2010, at 10:37 AM, Chris Browne wrote:
Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
EVANESCENT.
UNSAFE ?
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise,
On Dec 10, 2010, at 4:34 PM, Cédric Villemain wrote:
Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
EVANESCENT.
UNSAFE ?
LOLZ.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Thanks alot for all the replies. Very helpful, really appreciate it.
- Original Message -
From: Jeff Janes jeff.ja...@gmail.com
To: Hamza Bin Sohail hsoh...@purdue.edu
Cc: pgsql-hackers@postgresql.org
Sent: Friday, December 10, 2010 7:18 PM
Subject: Re: [HACKERS] would hw acceleration
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
How do you select which upgrade script to apply?
You run all those that contain version numbers higher than the
currently-installed one.
This of course assumes that one can correctly tell that one
1 - 100 of 115 matches
Mail list logo
