I have a C function (a trigger function) which uses the PG_TRY()
construct to handle certain ERROR conditions.
One example is where invoked as INSTEAD OF INSERT into a view. It
PG_TRYs INSERT into the real base table,
but this table may not yet exist (it is a partitioned child of an
My cut'n'pasting failed me at one point corrected below.
discussion about what is the difference between a synchronous read
versus an asynchronous read as far as non-originator waiting on it is
concerned.
I thought a bit more about this. There are currently two differences,
one of which
On Mon, Jun 23, 2014 at 2:43 PM, John Lumby johnlu...@hotmail.com wrote:
It is when some *other* backend gets there first with the ReadBuffer that
things are a bit trickier. The current version of the patch did polling for
that case
but that drew criticism, and so an imminent new version
and patch
On 06/24/2014 04:29 PM, John Lumby wrote:
On Mon, Jun 23, 2014 at 2:43 PM, John Lumby johnlu...@hotmail.com wrote:
It is when some *other* backend gets there first with the ReadBuffer that
things are a bit trickier. The current version of the patch did polling
for that case
Date: Thu, 19 Jun 2014 15:43:44 -0300
Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch
From: klaussfre...@gmail.com
To: st...@mit.edu
CC: hlinnakan...@vmware.com; johnlu...@hotmail.com;
pgsql-hackers@postgresql.org
On
Thanks Fujii , that is a bug -- an #ifdef USE_PREFETCH is missing in
heapam.c
(maybe several)
I will fix it in the next patch version.
I also appreciate it is not easy to review the patch.
There are really 4 (or maybe 5) parts :
. async io (librt functions)
. buffer
, John Lumby wrote:
The patch seems to assume that you can put the aiocb struct in shared
memory, initiate an asynchronous I/O request from one process, and wait
for its completion from another process. I'm pretty surprised if that
works on any platform.
It works on linux.Actually
I have pasted below the EXPLAIN of one of my benchmark queries
(the one I reference in the README).
Plenty of nested loop joins.
However I think I understand your question as to how effective it would be
if the outer is not sorted, and I will see if I can dig into that
if I get time (and it
Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 11:34 PM, Claudio Freire wrote:
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 04:12 PM, John Lumby wrote:
On 05/28/2014 11:52 PM, John Lumby wrote:
The patch seems to assume
From: t...@sss.pgh.pa.us
To: klaussfre...@gmail.com
CC: hlinnakan...@vmware.com; johnlu...@hotmail.com;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
Date: Thu, 29 May 2014 17:56:57 -0400
Claudio Freire
Date: Thu, 29 May 2014 18:00:28 -0300
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
From: klaussfre...@gmail.com
To: hlinnakan...@vmware.com
CC: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
Even if it worked on Linux today, it would
Bruce Momjian wrote:
On Fri, Nov 2, 2012 at 09:59:08AM -0400, John Lumby wrote:
However,the OP describes an implementation based on libaio.
Today what we have (for linux) is librt, which is quite different.
Well, good thing we didn't switch to using libaio, now that it is gone.
Yes
Claudio Freire wrote:
On Thu, Nov 1, 2012 at 10:59 PM, Greg Smith g...@2ndquadrant.com 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
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.
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 the
From: Claudio Freire klaussfre...@gmail.com
I hope I'm not talking to myself.
Indeed not. I also looked into prefetching for pure index scans for b-trees
(and extension to use async io).
http://archives.postgresql.org/message-id/BLU0-SMTP31709961D846CCF4F5EB4C2A3930%40phx.gbl
I am not
First, apologies for taking so long to reply to your post.
On Fri, 22 Jun 2012 09:55:13, Robert Haas wrote:
On Wed, Jun 20, 2012 at 12:24 PM, John Lumby johnlumby(at)hotmail(dot)com
wrote:
An INSERT which has a RETURNING clause and which is to be rewritten
based on
a rule
---
Problem I'm trying to solve:
For partitioned tables, make it possible to use RETURNING clause on INSERT
INTO
together with DO INSTEAD rule
[ Note - wherever I say INSERT I also mean UPDATE and DELETE ]
---
18 matches
Mail list logo
