Re: [HACKERS] pg_prewarm

2012-03-09 Thread Dimitri Fontaine
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

Re: [HACKERS] pg_prewarm

2012-03-09 Thread Robert Haas
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

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

2012-03-09 Thread Etsuro Fujita
(2012/03/09 14:00), Tom Lane wrote: I wrote: There are a couple of other points that make me think we need to revisit the PlanForeignScan API definition some more, too. ... So we need to break down what PlanForeignScan currently does into three separate steps. The first idea that comes to mind

Re: [HACKERS] pg_stats_recovery view

2012-03-09 Thread Fujii Masao
On Tue, Feb 14, 2012 at 4:10 PM, Jaime Casanova wrote: > On Thu, Feb 2, 2012 at 2:32 AM, Magnus Hagander wrote: >> >> I haven't looked through the code in detail, but one direct comment: >> do we really need/want to send this through the stats collector? It >> will only ever have one sender - per

Re: [HACKERS] xlog location arithmetic

2012-03-09 Thread Fujii Masao
On Sun, Mar 4, 2012 at 8:26 PM, Magnus Hagander wrote: > On Sun, Feb 26, 2012 at 00:53, Euler Taveira de Oliveira > wrote: >> On 25-02-2012 09:23, Magnus Hagander wrote: >>> Do we even *need* the validate_xlog_location() function? If we just >>> remove those calls, won't we still catch all the in

Re: [HACKERS] Command Triggers, patch v11

2012-03-09 Thread Thom Brown
On 9 March 2012 00:28, Thom Brown wrote: > On 8 March 2012 22:24, Dimitri Fontaine wrote: > > We're getting there. :) It was late last night and I forgot to get around to testing pg_dump, which isn't working correctly: -- -- Name: cmd_trg_after_alter_aggregate; Type: COMMAND TRIGGER; Schema: -

[HACKERS] Bug: walsender and high CPU usage

2012-03-09 Thread Fujii Masao
Hi, I found the bug which causes walsender to enter into busy loop when replication connection is terminated. Walsender consumes lots of CPU resource (%sys), and this situation lasts until it has detected the termination of replication connection and exited. The cause of this bug is that the wals

Re: [HACKERS] [PATCH] Support for foreign keys with arrays

2012-03-09 Thread Marco Nenciarini
Il giorno gio, 08/03/2012 alle 08.11 -0500, Robert Haas ha scritto: > On Fri, Feb 24, 2012 at 9:01 PM, Noah Misch wrote: > > I consider these the core changes needed to reach Ready for Committer: > > > > - Fix crash in array_replace(arr, null, null). > > - Don't look through the domain before call

Re: [HACKERS] Review of patch renaming constraints

2012-03-09 Thread Dimitri Fontaine
Hi, Peter Eisentraut writes: > On tor, 2012-01-12 at 22:43 -0600, Joshua Berkus wrote: >> Most normal uses of alter table ... rename constraint ... worked >> normally. However, the patch does not deal correctly with constraints >> which are not inherited, such as primary key constraints: > > New

Re: [HACKERS] pg_prewarm

2012-03-09 Thread Hans-Jürgen Schönig
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

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

2012-03-09 Thread Fujii Masao
On Fri, Mar 9, 2012 at 7:04 PM, Heikki Linnakangas wrote: > Here's an updated patch. It now only loops once per segment that a record > crosses. Plus a lot of other small cleanup. Thanks! But you forgot to attach the patch. > I've been doing some performance testing with this, using a simple C >

Re: [HACKERS] pg_prewarm

2012-03-09 Thread Fujii Masao
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.

Re: Scaling XLog insertion (was Re: [HACKERS] Moving more work outside WALInsertLock)

2012-03-09 Thread Heikki Linnakangas
On 07.03.2012 17:28, Tom Lane wrote: Simon Riggs writes: On Wed, Mar 7, 2012 at 3:04 PM, Tom Lane wrote: Alvaro Herrera writes: So they are undoubtely rare. Not sure if as rare as Higgs bosons. Even if they're rare, having a major performance hiccup when one happens is not a side-effect

Re: [HACKERS] pg_prewarm

2012-03-09 Thread Devrim GÜNDÜZ
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.

Re: [HACKERS] pg_prewarm

2012-03-09 Thread Joshua Drake
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

<    1   2