Sorry, this is not a typo. Please ignore the post.
Best regards,
Etsuro Fujit
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Friday, November 02, 2012 2:40 PM
> To: 'PostgreSQL-development'
This is a little patch to fix a typo in a comment.
Best regards,
Etsuro Fujit
commentfix_20121102.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 1, 2012 at 10:59 PM, Greg Smith wrote:
> On 11/1/12 6:13 PM, Claudio Freire wrote:
>
>> posix_fadvise what's the trouble there, but the fact that the kernel
>> stops doing read-ahead when a call to posix_fadvise comes. I noticed
>> the performance hit, and checked the kernel's code. It
On 11/1/12 6:13 PM, Claudio Freire wrote:
posix_fadvise what's the trouble there, but the fact that the kernel
stops doing read-ahead when a call to posix_fadvise comes. I noticed
the performance hit, and checked the kernel's code. It effectively
changes the prediction mode from sequential to fa
On 10/31/12 12:17 PM, Magnus Hagander wrote:
The idea at the time was to use the include *directory* functionality,
for say a "config.d" directory in pgdata. The builtin one would then
use a predictable filename in this directory, so that the DBA who
prefers it can drop files both before and aft
On 11/1/12 11:54 PM, Josh Berkus wrote:
For example, it would be really useful to be able to
see, for example, pg_stat_user_tables from 2 days ago to estimate table
growth and activity, or pg_stat_replication from 10 minutes ago to
average replication lag.
I don't see all that going into core w
On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus wrote:
> Greg,
>
> First off, let me again praise the great work you and Peter are doing in
> this area.
> > Modeling this on pg_stat_statements includes the hope of packaging it as
> > an extension with minor core hooks, and the idea that there would b
Greg,
First off, let me again praise the great work you and Peter are doing in
this area.
> Modeling this on pg_stat_statements includes the hope of packaging it as
> an extension with minor core hooks, and the idea that there would be a
> fixed size list of timing events available at any time. C
Parsing log files for commonly needed performance data is no fun. As a
next step toward eliminating that, I've been working on how to approach
this similarly to how pg_stat_statements can cut down on query log
processing. I thought it would be novel to outline this for design
review before co
Hi All,
We are using postgreSQL since 2007 (now we use postgreSQL 8.4) and until
recently we used to perform vacuum and analyze tasks by ourself. Nevertheless
we reached a point where these tasks are taking so much time that why we decide
to use the autovacuum daemon.
But we have some diffic
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
wrote:
> Btw, I believe that this is correct behavior, because in Peter's case the
> manual command gets the priority on the value of synchronous_commit, no?
> If anybody thinks that I am wrong, feel free to argue on that of course...
The idea of
Claudio wrote :
>
> Check the latest patch, it contains heap page prefetching too.
>
Oh yes I see. I missed that - I was looking in the wrong place.
I do have one question about the way you did it : by placing the
prefetch heap-page calls in _bt_next, which effectively means inside
a call from th
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter wrote:
> I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
> enough latency for my reflexes to hit ^C fast enough. Any way to
> inject this fault deterministically?
>
If the point is to get this warning, you can always setup
synch
>> Since I've mentioned my use case, I might as well mention another issue I
>> stumbled across, which is that concurrent index creation cannot happen from
>> within trigger functions. I'm able to non-concurrently create indexes from
>> within trigger functions. Why is there this disparity?
>
Hi,
On Monday 29 October 2012 16:33:25 Tom Lane wrote:
> Christian Kruse writes:
> > I created a patch which implements MAP_HUGETLB for sysv shared memory
> > segments (PGSharedMemoryCreate). It is based on tests of Tom Lane and
> > Andres Freund, I added error handling, huge page size detection
On 28 October 2012 01:20, David Lee wrote:
> It seems like right now when you want to create an index concurrently, the
> index creation will get canceled if you cancel the statement (i.e. you must
> keep your statement open).
>
> Is there a way to "launch" an index creation in the background s
On Thu, Nov 1, 2012 at 2:00 PM, Andres Freund wrote:
>> > I agree. I'm a bit hesitant to subscribe to yet another mailing list
>>
>> FYI you can send messages to linux-kernel without subscribing (there's
>> no moderation either).
>>
>> Subscribing to linux-kernel is like drinking from a firehose :
On Thu, Nov 1, 2012 at 1:37 PM, John Lumby wrote:
>
> Claudio wrote :
>>
>> Oops - forgot to effectively attach the patch.
>>
>
> I've read through your patch and the earlier posts by you and Cédric.
>
> This is very interesting. You chose to prefetch index btree (key-ptr)
> pages
> whereas
On Thursday, November 01, 2012 05:53:39 PM Marti Raudsepp wrote:
> On Tue, Oct 30, 2012 at 1:50 AM, Claudio Freire
wrote:
> > On Mon, Oct 29, 2012 at 7:07 PM, Cédric Villemain
> >
> > wrote:
> >> Well, informing linux hackers may help.
> >
> > I agree. I'm a bit hesitant to subscribe to yet an
On Tue, Oct 30, 2012 at 1:50 AM, Claudio Freire wrote:
> On Mon, Oct 29, 2012 at 7:07 PM, Cédric Villemain
> wrote:
>> Well, informing linux hackers may help.
>
> I agree. I'm a bit hesitant to subscribe to yet another mailing list
FYI you can send messages to linux-kernel without subscribing (t
Claudio wrote :
>
> Oops - forgot to effectively attach the patch.
>
I've read through your patch and the earlier posts by you and Cédric.
This is very interesting. You chose to prefetch index btree (key-ptr) pages
whereas I chose to prefetch the data pages pointed to by the key-ptr pages.
Qi Huang wrote:
> I need to estimate the hashjoin cost in my research.
> I looked at the code of final_cost_hashjoin() . It is not clear
> what factor it is considering. So, except the I/O to and from disk,
> what other factors are affecting the cost of hahsjoin?
http://www.postgresql.org/docs/9
On 01/11/12 00:25, Baptiste LHOSTE wrote:
Hi All,
We are using postgreSQL since 2007 (now we use postgreSQL 8.4) and until
recently we used to perform vacuum and analyze tasks by ourself. Nevertheless
we reached a point where these tasks are taking so much time that why we decide
to use the a
Hi, Dear HackersI need to estimate the hashjoin cost in my research. As the
textbook shows, it is 3(R+S) where R and S are the size of the tablesize of the
two tables, which realistically only considers the cost of IO. But this is
obviously too theoretical. What is the correct way to estimat
On Wednesday, October 31, 2012 5:47 PM Magnus Hagander wrote:
On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane wrote:
> Josh Berkus writes:
I should think that doing this requires heading back towards there
being a single unique configuration stream, and over the course of
several versio
25 matches
Mail list logo
