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
> th
On Tue, Nov 11, 2014 at 6:17 AM, 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.
Oops.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
On Tue, Nov 11, 2014 at 8:17 PM, 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
>
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 Fre
On Sun, Jun 24, 2012 at 1:36 PM, Cédric Villemain wrote:
> 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 Wind
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 a
> 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/
Po
On 7/10/12 5:22 AM, Dimitri Fontaine wrote:
> Jeff Janes 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 understa
Jeff Janes 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 a patch for
pgfinc
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
> singl
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 an
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 w
> 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 pa
Robert Haas 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 (pgsql-hackers@postgresql.org)
To make change
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 pgfi
> 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 pat
On Wed, Jun 20, 2012 at 3:53 PM, Peter Eisentraut 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 be better to
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
> > 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 pg
On Sun, Mar 18, 2012 at 7:25 AM, Cédric Villemain
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 functions (buff
> 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 pg_prew
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao 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: http://www.enterprisedb.com
The Ent
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 curre
Le vendredi 9 mars 2012 16:50:05, Robert Haas a écrit :
> On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
>
> 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
Hi Robert
2012/3/11 Robert Haas :
> On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller 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 rep
On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller 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 be used th
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 Mar 9, 2012, at 2:34 PM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
> 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 (sort
On Fri, Mar 9, 2012 at 10:53 AM, Jeff Janes wrote:
> On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao wrote:
>>> When a relation is loaded into cache, are corresponding indexes also loaded
>>> at the same time?
>>
>> No, although if you wanted to
On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao 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:
On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
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 seems tricky, though.
Robert Haas 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 buffers related
faci
On Fri, Mar 9, 2012 at 8:25 AM, Dimitri Fontaine wrote:
> Robert Haas 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
On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
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 profile" on
> st
Robert Haas 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 about pgfincore mayb
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao 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', 'read', NULL, NULL) fr
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 1:13 PM, 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.
>
> 2.
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.
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 y
On Thu, Mar 8, 2012 at 11:13 PM, 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.
>
wel
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 dat
42 matches
Mail list logo
