On 2014-11-11 12:17:11 +0100, Andres Freund wrote:
pg_prewarm() currently can't be cannot be interrupted - which seems odd
given that it's intended to read large amounts of data from disk. A
rather slow process.
Unless somebody protests I'm going to add a check to the top of each of
the
Hi,
pg_prewarm() currently can't be cannot be interrupted - which seems odd
given that it's intended to read large amounts of data from disk. A
rather slow process.
Unless somebody protests I'm going to add a check to the top of each of
the three loops.
Greetings,
Andres Freund
--
Andres
On Tue, Nov 11, 2014 at 8:17 PM, Andres Freund and...@2ndquadrant.com wrote:
pg_prewarm() currently can't be cannot be interrupted - which seems odd
given that it's intended to read large amounts of data from disk. A
rather slow process.
Unless somebody protests I'm going to add a check to
On Tue, Nov 11, 2014 at 6:17 AM, Andres Freund and...@2ndquadrant.com wrote:
pg_prewarm() currently can't be cannot be interrupted - which seems odd
given that it's intended to read large amounts of data from disk. A
rather slow process.
Oops.
--
Robert Haas
EnterpriseDB:
On Sun, Jun 24, 2012 at 1:36 PM, Cédric Villemain ced...@2ndquadrant.comwrote:
Le samedi 23 juin 2012 02:47:15, Josh Berkus a écrit :
The biggest problem with pgfincore from my point of view is that it
only works under Linux, whereas I use a MacOS X machine for my
development, and there
I hope it's not too late for another reviewer to pitch in :) I have let
some time pass between previous reviews so that I can give this patch a
fresh look, and not be tainted by what the other reviews said, so I may be
repeating a few things already covered by other reviewers. I haven't
performed
c) isn't necessarily safe in production (I've crashed Linux with Fincore
in the recent past).
fincore is another soft, please provide a bugreport if you hit issue with
pgfincore, I then be able to fix it and all can benefit.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
Jeff Janes jeff.ja...@gmail.com writes:
I think we want this. There is some discussion about how much overlap
it has with pgfincore, but I don't think there is an active proposal
to put that into contrib, so don't see that as blocking this.
It is my understanding that Cédric wants to propose
On 7/10/12 5:22 AM, Dimitri Fontaine wrote:
Jeff Janes jeff.ja...@gmail.com writes:
I think we want this. There is some discussion about how much overlap
it has with pgfincore, but I don't think there is an active proposal
to put that into contrib, so don't see that as blocking this.
It is
This is a review for pg_prewarm V2.
It applies (with some fuzz, but it is handled correctly) and builds cleanly.
It includes docs, but does not include regression tests, which it
probably should (just to verify that it continues to compile and
execute without throwing errors, I wouldn't expect
From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
on behalf of Jeff Janes [jeff.ja...@gmail.com]
For the implementation:
1)
I think that for most users, making them know or care about forks and
block numbers is too much. It would be nice if there were a
Le samedi 23 juin 2012 02:47:15, Josh Berkus a écrit :
The biggest problem with pgfincore from my point of view is that it
only works under Linux, whereas I use a MacOS X machine for my
development, and there is also Windows to think about. Even if that
were fixed, though, I feel we ought
Robert Haas robertmh...@gmail.com writes:
73%? I think it's got about 15% overlap.
83.7% of stats are wrong. This one included.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list
The biggest problem with pgfincore from my point of view is that it
only works under Linux, whereas I use a MacOS X machine for my
development, and there is also Windows to think about. Even if that
were fixed, though, I feel we ought to have something in the core
distribution. This patch
On tis, 2012-04-10 at 13:29 +0200, Cédric Villemain wrote:
I have no problem deprecating overlapping features from pgfincore as
soon as I can do a «depend:pg_prewarm[os_warm]» :) ...It would have
been better to split pgfincore analyze and warming parts times
ago, anyway.
So pg_prewarm is
On Wed, Jun 20, 2012 at 3:53 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm worried about the overlap with pgfincore. It's pretty well
established in this space, and has about 73% feature overlap with
pg_prewarm, while having more features all together. So it would seem
to me that it would
The biggest problem with pgfincore from my point of view is that it
only works under Linux, whereas I use a MacOS X machine for my
development, and there is also Windows to think about. Even if that
were fixed, though, I feel we ought to have something in the core
distribution. This patch
Le mercredi 20 juin 2012 21:53:43, Peter Eisentraut a écrit :
On tis, 2012-04-10 at 13:29 +0200, Cédric Villemain wrote:
I have no problem deprecating overlapping features from pgfincore as
soon as I can do a «depend:pg_prewarm[os_warm]» :) ...It would have
been better to split pgfincore
pgfincore does not use the postgresql buffer manager, it uses the posix
calls. It can proceed per block or full relation.
Both need POSIX_FADVISE compatible system to be efficient.
The main difference between pgfincore and pg_prewarm about full relation
warm is that pgfincore will
On Sun, Mar 18, 2012 at 7:25 AM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Would be nice to sort out the features of the two Postgres extentions
pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
do they have in common, what is complementary?
pg_prewarm use postgresql
Would be nice to sort out the features of the two Postgres extentions
pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
do they have in common, what is complementary?
pg_prewarm use postgresql functions (buffer manager) to warm data (different
kind of 'warm', see
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao masao.fu...@gmail.com wrote:
For such system, so far I've been suggesting using pgstatindex, but it's good
if pg_prewarm can do that.
Relevant to this, see commit 2e46bf67114586835f4a9908f1a1f08ee8ba83a8.
--
Robert Haas
EnterpriseDB:
Hi Robert
2012/3/11 Robert Haas robertmh...@gmail.com:
On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller sfkel...@gmail.com wrote:
The main conclusion was:
* Do a tar cf /dev/zero $PG_DATA/base either shortly before or
shortly after the database is created
* Do a seq scan SELECT * FROM
Le vendredi 9 mars 2012 16:50:05, Robert Haas a écrit :
On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
So that's complementary with pgfincore, ok. I still wish we could
maintain the RAM content HOT on the standby in the same way we are able
to maintain
Cédric and Robert
Thanks, Cédric, for the reminder.
Would be nice to sort out the features of the two Postgres extentions
pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
do they have in common, what is complementary?
I would be happy to test both. But when reading the
On Mar 9, 2012, at 2:34 PM, Robert Haas wrote:
On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
postg...@cybertec.at wrote:
we had some different idea here in the past: what if we had a procedure /
method to allow people to save the list of current buffers / cached blocks
to be written
Hi Robert,
Just recently I asked on postgres-performance PG as in-memory db? How
to warm up and re-populate buffers? How to read in all tuples into
memory?
Somehow open was, what's the best practice of configuration and
relationship between disk/OS cache vs. Portgres cache
The main conclusion
On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller sfkel...@gmail.com wrote:
The main conclusion was:
* Do a tar cf /dev/zero $PG_DATA/base either shortly before or
shortly after the database is created
* Do a seq scan SELECT * FROM osm_point.
Is your tool a replacement of those above?
It can
So I wrote a prewarming utility. Patch is attached. You can prewarm
either the OS cache or PostgreSQL's cache, and there are two options for
prewarming the OS cache to meet different needs. By passing the correct
arguments to the function, you can prewarm an entire relation or just
the blocks
Hi,
On Thu, 2012-03-08 at 23:13 -0500, Robert Haas wrote:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this purpose.
On Fri, Mar 9, 2012 at 1:13 PM, Robert Haas robertmh...@gmail.com wrote:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this
we had some different idea here in the past: what if we had a procedure /
method to allow people to save the list of current buffers / cached blocks to
be written to disk (sorted). we could then reload this cache profile on
startup in the background or people could load a certain cache content
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao masao.fu...@gmail.com wrote:
When a relation is loaded into cache, are corresponding indexes also loaded
at the same time?
No, although if you wanted to do that you could easily do so, using a
query like this:
select pg_prewarm(indexrelid, 'main',
Robert Haas robertmh...@gmail.com writes:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this purpose.
Try telling them
On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
postg...@cybertec.at wrote:
we had some different idea here in the past: what if we had a procedure /
method to allow people to save the list of current buffers / cached blocks to
be written to disk (sorted). we could then reload this cache
On Fri, Mar 9, 2012 at 8:25 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they
Robert Haas robertmh...@gmail.com writes:
https://github.com/klando/pgfincore
Oh, huh. I had no idea that pgfincore could do that. I thought that
was just for introspection; I didn't realize it could actually move
data around for you.
Well, I though Cédric already had included shared
On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
So that's complementary with pgfincore, ok. I still wish we could
maintain the RAM content HOT on the standby in the same way we are able
to maintain its data set on disk, though.
That's an interesting idea. It
On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao masao.fu...@gmail.com wrote:
When a relation is loaded into cache, are corresponding indexes also loaded
at the same time?
No, although if you wanted to do that you could
On Fri, Mar 9, 2012 at 10:53 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao masao.fu...@gmail.com wrote:
When a relation is loaded into cache, are corresponding indexes also loaded
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this purpose.
2. Sometimes when I'm benchmarking stuff, I want to get all the
On Thu, Mar 8, 2012 at 11:13 PM, Robert Haas robertmh...@gmail.com wrote:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for
42 matches
Mail list logo
