Re: [HACKERS] Inlining comparators as a performance optimisation

On Tue, Sep 20, 2011 at 3:51 AM, Tom Lane wrote: >> This performance patch differs from most in that it's difficult in >> principle to imagine a performance regression occurring. > > Really?  N copies of the same code could lead to performance loss just > due to code bloat (ie, less of a query's

Re: [HACKERS] Inlining comparators as a performance optimisation

On 21.09.2011 02:53, Peter Geoghegan wrote: C stdlib quick-sort time elapsed: 2.092451 seconds Inline quick-sort time elapsed: 1.587651 seconds Does *that* look attractive to you? Not really, to be honest. That's a 25% speedup in pure qsorting speed. How much of a gain in a real query do you

Re: [HACKERS] Online base backup from the hot-standby

On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander wrote: > On Wed, Sep 21, 2011 at 04:50, Fujii Masao wrote: >> 3. Copy the pg_control file from the cluster directory on the standby to >>    the backup as follows: >> >>    cp $PGDATA/global/pg_control /mnt/server/backupdir/global > > But this is d

Re: [HACKERS] WIP: Join push-down for foreign tables

Hi Michael, (2011/09/21 12:52), Michael Paquier wrote: > I am interested in the development you are doing regarding join push down > and fdw stuff for remote postgreSQL servers. > Is there a way to get the postgres fdw you are providing here for common > 9.1? > I saw that the tar you are providing

Re: [HACKERS] Online base backup from the hot-standby

On Wed, Sep 21, 2011 at 04:50, Fujii Masao wrote: > 2011/9/13 Jun Ishiduka : >> >> Update patch. >> >> Changes: >>  * set 'on' full_page_writes by user (in document) >>  * read "FROM: XX" in backup_label (in xlog.c) >>  * check status when pg_stop_backup is executed (in xlog.c) > > Thanks for upda

Re: [HACKERS] Back-branch releases upcoming this week

On tis, 2011-09-20 at 10:28 -0400, Tom Lane wrote: > I don't think we've yet decided what the policy means if a release > happens during the stated calendar month, which seems rather likely > this time around in view of our historical record of doing updates > roughly quarterly. Should we settle t

Re: [HACKERS] WIP: Join push-down for foreign tables

Hi, I am interested in the development you are doing regarding join push down and fdw stuff for remote postgreSQL servers. Is there a way to get the postgres fdw you are providing here for common 9.1? I saw that the tar you are providing here is adapted only for your patch. Regards, Michael 201

Re: [HACKERS] Isolation tests still falling over routinely

Alvaro Herrera writes: > The main problem I have is that I haven't found a way to reproduce the > problems in my machine. Try -DCLOBBER_CACHE_ALWAYS. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Is there really no interest in SQL Standard?

On tis, 2011-09-20 at 11:12 -0300, Alvaro Herrera wrote: > > > +1 for a closed mailing list. It's a bit annoying to have to do > such > > > a thing, but it's not like we haven't got other closed lists for > > > appropriate purposes. > > > > Well, that much we've already decided a few years ago.

Re: [HACKERS] Online base backup from the hot-standby

2011/9/13 Jun Ishiduka : > > Update patch. > > Changes: >  * set 'on' full_page_writes by user (in document) >  * read "FROM: XX" in backup_label (in xlog.c) >  * check status when pg_stop_backup is executed (in xlog.c) Thanks for updating the patch. Before reviewing the patch, to encourage peopl

Re: [HACKERS] EXPLAIN and nfiltered, take two

On Tue, Sep 20, 2011 at 8:19 PM, Tom Lane wrote: > Marko Tiikkaja writes: >>> The attached patch is the best I could come up with.  I considered >>> showing "Rows Removed by Foo: (never executed)" and omitting the line >>> altogether, but I didn't particularly like either of those options.  The >

Re: [HACKERS] Isolation tests still falling over routinely

Excerpts from Kevin Grittner's message of mar sep 20 22:51:39 -0300 2011: > If I remember right, Alvaro chose these timings to balance run time > against chance of failure. Unless we want to remove these deadlock > handling tests or ignore failures (which both seem like bad ideas to > me), I thi

Re: [HACKERS] Isolation tests still falling over routinely

Tom Lane wrote: > The buildfarm is still showing isolation test failures more days > than not, eg > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pika&dt=2011-09-17%2012%3A43%3A11 > and I've personally seen such failures when testing with > CLOBBER_CACHE_ALWAYS. Could we please fix tho

Re: [HACKERS] Inlining comparators as a performance optimisation

- Цитат от Peter Geoghegan (pe...@2ndquadrant.com), на 21.09.2011 в 02:53 - > On 20 September 2011 03:51, Tom Lane wrote: >> Considering that -O2 is our standard optimization level, that >> observation seems to translate to "this patch will be useless in >> practice".  I think you had be

Re: [HACKERS] WIP: Collecting statistics on CSV file data

Excerpts from David Fetter's message of mar sep 20 21:22:32 -0300 2011: > On Tue, Sep 20, 2011 at 11:13:05AM -0400, Tom Lane wrote: > > Probably a more interesting question is why we wouldn't change > > autovacuum so that it calls this automatically for foreign tables. > > How about a per-table

[HACKERS] Isolation tests still falling over routinely

The buildfarm is still showing isolation test failures more days than not, eg http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pika&dt=2011-09-17%2012%3A43%3A11 and I've personally seen such failures when testing with CLOBBER_CACHE_ALWAYS. Could we please fix those tests to not have such fra

Re: [HACKERS] WIP: Collecting statistics on CSV file data

On Tue, Sep 20, 2011 at 11:13:05AM -0400, Tom Lane wrote: > Marti Raudsepp writes: > > 2011/9/12 Etsuro Fujita : > >> This is called when ANALYZE command is executed. (ANALYZE > >> command should be executed because autovacuum does not analyze foreign > >> tables.) > > > This is a good idea. > >

Re: [HACKERS] EXPLAIN and nfiltered, take two

Marko Tiikkaja writes: >> The attached patch is the best I could come up with. I considered >> showing "Rows Removed by Foo: (never executed)" and omitting the line >> altogether, but I didn't particularly like either of those options. The >> current patch simply displays "Rows Removed by Foo

Re: [HACKERS] Inlining comparators as a performance optimisation

On 20 September 2011 03:51, Tom Lane wrote: > Considering that -O2 is our standard optimization level, that > observation seems to translate to "this patch will be useless in > practice".  I think you had better investigate that aspect in some > detail before spending more effort. I don't think t

Re: [HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX

MUHAMMAD ASIF writes: > I faced similar issue as discussed in > "http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html";. > (man xopen_networking - > http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html) > ... There are two wa

Re: [HACKERS] EXPLAIN and nfiltered, take two

Marko Tiikkaja writes: > The attached patch is the best I could come up with. I considered > showing "Rows Removed by Foo: (never executed)" and omitting the line > altogether, but I didn't particularly like either of those options. The > current patch simply displays "Rows Removed by Foo: 0"

Re: [HACKERS] Is there really no interest in SQL Standard?

On Tue, Sep 20, 2011 at 04:51:51PM +0300, Peter Eisentraut wrote: > On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote: > > Peter Eisentraut writes: > > > On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote: > > >> That is much more reasonable, though unfortunately not what was said. > > >> Regardle

[HACKERS] PostgreSQL X/Open Socket / BSD Socket Issue on HP-UX

Hi, I faced similar issue as discussed in "http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html";. (man xopen_networking - http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html) ... There are two ways to obtain X/Open Socket

Re: [HACKERS] CUDA Sorting

> > I already did some benchmarks with GPU sorting (not in pgsql), and > measured total sort times, copy bandwidth and energy usage, and got > some exciting results: Was that qsort implementation on CPU cache friendly and optimized for SSE ? To make a fair comparison you have to take the best CPU i

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Tue, Sep 20, 2011 at 3:10 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote: >>> Are we all talking about the same thing?  In my mind recovery.conf is >>> for configuring a point-in-time archive recovery run.  It's got nothing >>> to do with either r

Re: [HACKERS] unite recovery.conf and postgresql.conf

> The point I'm trying to make is that it seems like this discussion is > getting driven entirely by the standby case, without remembering that > recovery.conf was originally designed for, and is still used in, > a significantly different use-case. Maybe we had better take two > steps back and th

Re: [HACKERS] heap_update temporary release of buffer lock

Alvaro Herrera writes: > Excerpts from Robert Haas's message of mar sep 20 16:04:03 -0300 2011: >>> On 20.09.2011 20:42, Alvaro Herrera wrote: I notice that heap_update releases the buffer lock, after checking the HeapTupleSatifiesUpdate result, and before marking the tuple as updated, >

Re: [HACKERS] heap_update temporary release of buffer lock

Excerpts from Robert Haas's message of mar sep 20 16:04:03 -0300 2011: > On Tue, Sep 20, 2011 at 2:28 PM, Heikki Linnakangas > wrote: > > On 20.09.2011 20:42, Alvaro Herrera wrote: > >> I notice that heap_update releases the buffer lock, after checking the > >> HeapTupleSatifiesUpdate result, and

Re: [HACKERS] unite recovery.conf and postgresql.conf

Robert Haas writes: > On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote: >> Are we all talking about the same thing?  In my mind recovery.conf is >> for configuring a point-in-time archive recovery run.  It's got nothing >> to do with either replication or standbys. > Huh? How else can you create

Re: [HACKERS] heap_update temporary release of buffer lock

On Tue, Sep 20, 2011 at 2:28 PM, Heikki Linnakangas wrote: > On 20.09.2011 20:42, Alvaro Herrera wrote: >> I notice that heap_update releases the buffer lock, after checking the >> HeapTupleSatifiesUpdate result, and before marking the tuple as updated, >> to pin the visibility map page -- heapam.

Re: [HACKERS] Back-branch releases upcoming this week

Tom Lane wrote: Dave Page writes: On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane wrote: As has been mentioned a couple times, we're well overdue for updates of the back branches. �Seems like time to get that done, so we'll be wrapping 8.2.x and up this Thursday for release Monday the 26th. 8.2

Re: [HACKERS] heap_update temporary release of buffer lock

On 20.09.2011 20:42, Alvaro Herrera wrote: I notice that heap_update releases the buffer lock, after checking the HeapTupleSatifiesUpdate result, and before marking the tuple as updated, to pin the visibility map page -- heapam.c lines 2638ff in master branch. Is this not a bug? I imagine that

Re: [HACKERS] File not found error on creating collation

On 20 September 2011 18:25, Tom Lane wrote: > Thom Brown writes: >> On 20 September 2011 17:45, Tom Lane wrote: >>> BTW, on examining the code I note that we're doing something else that >>> promotes the confusion of "bad locale name" with "bad file name": we're >>> using errcode_for_file_access

[HACKERS] heap_update temporary release of buffer lock

I notice that heap_update releases the buffer lock, after checking the HeapTupleSatifiesUpdate result, and before marking the tuple as updated, to pin the visibility map page -- heapam.c lines 2638ff in master branch. Is this not a bug? I imagine that while this code releases the lock, someone e

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote: > Josh Berkus writes: >> First, if we're going to change behavior, I assert that we should stop >> calling stuff "recovery" and either call it "replica" or "standby".  Our >> use of the word "recovery" confuses users; it is historical in nature >>

Re: [HACKERS] unite recovery.conf and postgresql.conf

Josh Berkus writes: > First, if we're going to change behavior, I assert that we should stop > calling stuff "recovery" and either call it "replica" or "standby". Our > use of the word "recovery" confuses users; it is historical in nature > and requires an understanding of PostgreSQL internals to

Re: [HACKERS] File not found error on creating collation

Thom Brown writes: > On 20 September 2011 17:45, Tom Lane wrote: >> BTW, on examining the code I note that we're doing something else that >> promotes the confusion of "bad locale name" with "bad file name": we're >> using errcode_for_file_access() to select the SQLSTATE.  If we don't >> believe

Re: [HACKERS] unite recovery.conf and postgresql.conf

On 9/20/11 10:09 AM, Robert Haas wrote: > I like the idea of some kind of sentinel file that tells the server to > start up in recovery mode. But instead of having the user remove it > to cause a promotion, I think the server should remove it when it does > promote. That's more like what we've do

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Tue, Sep 20, 2011 at 1:01 PM, Josh Berkus wrote: > I'll go further and say that we only want one trigger file by default, > one which either enables or disables recovery.  I'll further suggest > that we: > > a) have a standby.on file which puts the server in replica/recovery mode > if it's dete

Re: [HACKERS] unite recovery.conf and postgresql.conf

All, First, if we're going to change behavior, I assert that we should stop calling stuff "recovery" and either call it "replica" or "standby". Our use of the word "recovery" confuses users; it is historical in nature and requires an understanding of PostgreSQL internals to know why it's called t

Re: [HACKERS] File not found error on creating collation

On 20 September 2011 17:45, Tom Lane wrote: > Thom Brown writes: >> [ unhelpful reporting of ENOENT from newlocale() ] > > BTW, on examining the code I note that we're doing something else that > promotes the confusion of "bad locale name" with "bad file name": we're > using errcode_for_file_acce

Re: [HACKERS] File not found error on creating collation

Thom Brown writes: > [ unhelpful reporting of ENOENT from newlocale() ] BTW, on examining the code I note that we're doing something else that promotes the confusion of "bad locale name" with "bad file name": we're using errcode_for_file_access() to select the SQLSTATE. If we don't believe that

Re: [HACKERS] unite recovery.conf and postgresql.conf

> I don't buy this argument at all. I don't believe that recovery.conf is > part of anyone's automated processes at all, let alone to an extent that > they won't be able to cope with a change to rationalize the file layout. > And most especially I don't buy that someone who does want to keep usin

Re: [HACKERS] unite recovery.conf and postgresql.conf

Simon Riggs writes: > I sympathise with this view, to an extent. > If people want to put all parameters in one file, they can do so. So +1 to > that. > Should they be forced to adopt that new capability by us deliberately > breaking their existing setups? No. So -1 to that. > If we do an autom

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 11:01 AM, Marti Raudsepp wrote: > On Fri, Sep 16, 2011 at 01:53, Simon Riggs wrote: >> This patch splits bgwriter into 2 processes: checkpointer and >> bgwriter, seeking to avoid contentious changes. Additional changes are >> expected in this release to build upon these ch

Re: [HACKERS] File not found error on creating collation

Thom Brown writes: > On 20 September 2011 05:20, Tom Lane wrote: >> Robert Haas writes: >>> Maybe something like this? >>> HINT: The operating system was unable to find any locale data for the >>> locale name you specified. >> Hmm, that's not bad. We could probably even call it errdetail, sinc

Re: [HACKERS] WIP: Collecting statistics on CSV file data

On 20-09-2011 11:12, Marti Raudsepp wrote: 2011/9/12 Etsuro Fujita: This is called when ANALYZE command is executed. (ANALYZE command should be executed because autovacuum does not analyze foreign tables.) This is a good idea. However, if adding these statistics requires an explicit ANALYZE c

Re: [HACKERS] WIP: Collecting statistics on CSV file data

Marti Raudsepp writes: > 2011/9/12 Etsuro Fujita : >> This is called when ANALYZE command is executed. (ANALYZE >> command should be executed because autovacuum does not analyze foreign >> tables.) > This is a good idea. > However, if adding these statistics requires an explicit ANALYZE > comman

Re: [HACKERS] Back-branch releases upcoming this week

On Tue, Sep 20, 2011 at 3:57 PM, Tom Lane wrote: > Dave Page writes: >> On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane wrote: >>> As has been mentioned a couple times, we're well overdue for updates of >>> the back branches.  Seems like time to get that done, so we'll be >>> wrapping 8.2.x and up th

Re: [HACKERS] Separating bgwriter and checkpointer

On Fri, Sep 16, 2011 at 01:53, Simon Riggs wrote: > This patch splits bgwriter into 2 processes: checkpointer and > bgwriter, seeking to avoid contentious changes. Additional changes are > expected in this release to build upon these changes for both new > processes, though this patch stands on it

Re: [HACKERS] Back-branch releases upcoming this week

Dave Page writes: > On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane wrote: >> As has been mentioned a couple times, we're well overdue for updates of >> the back branches.  Seems like time to get that done, so we'll be >> wrapping 8.2.x and up this Thursday for release Monday the 26th. > 8.2 up, incl

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 9:35 AM, Heikki Linnakangas wrote: >> All that said my question is which way is the code more legible and >> easier to follow? > > Hear hear. If we're going to give the bgwriter more responsibilities, this > might make sense even if it has no effect on performance. I agree

Re: [HACKERS] Back-branch releases upcoming this week

2011/9/20 Tom Lane : > Dave Page writes: >> 2011/9/20 Andrew Dunstan : >>> On 09/20/2011 10:28 AM, Tom Lane wrote: does "after December" really mean "in or after December", or did we really mean "after"? > >>> If we really want to get that specific, let's just say that the EOL date is >>

Re: [HACKERS] Separating bgwriter and checkpointer

On 20.09.2011 17:31, Cédric Villemain wrote: 2011/9/20 Heikki Linnakangas: On 20.09.2011 16:49, Magnus Hagander wrote: Isn't there also the advantage of that work put in two different processes can use two different CPU cores? Or is that likely to never ever come in play here? You would need

Re: [HACKERS] Back-branch releases upcoming this week

Dave Page writes: > 2011/9/20 Andrew Dunstan : >> On 09/20/2011 10:28 AM, Tom Lane wrote: >>> does "after December" really mean "in or after December", or did we >>> really mean "after"? >> If we really want to get that specific, let's just say that the EOL date is >> at the end of the designated

Re: [HACKERS] Back-branch releases upcoming this week

2011/9/20 Andrew Dunstan : > > > On 09/20/2011 10:28 AM, Tom Lane wrote: >> >> I don't think we've yet decided what the policy means if a release >> happens during the stated calendar month, which seems rather likely >> this time around in view of our historical record of doing updates >> roughly q

Re: [HACKERS] Back-branch releases upcoming this week

On 09/20/2011 10:28 AM, Tom Lane wrote: I don't think we've yet decided what the policy means if a release happens during the stated calendar month, which seems rather likely this time around in view of our historical record of doing updates roughly quarterly. Should we settle that detail now

Re: [HACKERS] Separating bgwriter and checkpointer

2011/9/20 Heikki Linnakangas : > On 20.09.2011 16:49, Magnus Hagander wrote: >> >> Isn't there also the advantage of that work put in two different >> processes can use two different CPU cores? Or is that likely to never >> ever come in play here? > > You would need one helluva I/O system to satura

Re: [HACKERS] Back-branch releases upcoming this week

Andrew Dunstan writes: > On 09/20/2011 02:46 AM, Devrim GÜNDÜZ wrote: >> Can we also specify a final release version for 8.2? This set will be >> 8.2.21, and I propose to EOL 8.2 as of 8.2.22. > I don't see why we should deviate from the policy at >

Re: [HACKERS] Separating bgwriter and checkpointer

On 20.09.2011 16:49, Magnus Hagander wrote: Isn't there also the advantage of that work put in two different processes can use two different CPU cores? Or is that likely to never ever come in play here? You would need one helluva I/O system to saturate even a single CPU, just by doing write+fs

Re: [HACKERS] WIP: Collecting statistics on CSV file data

2011/9/12 Etsuro Fujita : > This is called when ANALYZE command is executed. (ANALYZE > command should be executed because autovacuum does not analyze foreign > tables.) This is a good idea. However, if adding these statistics requires an explicit ANALYZE command, then we should also have a comma

Re: [HACKERS] Is there really no interest in SQL Standard?

Excerpts from Peter Eisentraut's message of mar sep 20 10:51:51 -0300 2011: > On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote: > > Peter Eisentraut writes: > > > On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote: > > >> That is much more reasonable, though unfortunately not what was said. > >

Re: [HACKERS] Is there really no interest in SQL Standard?

On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote: > >> That is much more reasonable, though unfortunately not what was said. > >> Regardless, I stand by my main point that such a representative should > >> be commu

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 15:35, Heikki Linnakangas wrote: > On 20.09.2011 16:29, Greg Stark wrote: >> >> On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs >>  wrote: I don't see what difference it makes which process does the I/O. If a write() by checkpointer process blocks, any write()s

Re: [HACKERS] Separating bgwriter and checkpointer

On 20.09.2011 16:29, Greg Stark wrote: On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs wrote: I don't see what difference it makes which process does the I/O. If a write() by checkpointer process blocks, any write()s by the separate bgwriter process at that time will block too. If the I/O is not

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs wrote: >> I don't see what difference it makes which process does the I/O. If a >> write() by checkpointer process blocks, any write()s by the separate >> bgwriter process at that time will block too. If the I/O is not saturated, >> and the checkpoint

Re: [HACKERS] Back-branch releases upcoming this week

On 09/20/2011 02:46 AM, Devrim GÜNDÜZ wrote: On Tue, 2011-09-20 at 01:37 -0400, Tom Lane wrote: As has been mentioned a couple times, we're well overdue for updates of the back branches. Seems like time to get that done, so we'll be wrapping 8.2.x and up this Thursday for release Monday the 2

Re: [HACKERS] Grouping Sets

Hello 2011/9/20 David Rinaldi : > Since it seems that you have spent some considerable time investigating and > producing a working concept, what would your best guess time estimate be, > assuming the requisite skills/talent/will in (planner/executor/etc.), to > have a solid working module put tog

Re: [HACKERS] Grouping Sets

Since it seems that you have spent some considerable time investigating and producing a working concept, what would your best guess time estimate be, assuming the requisite skills/talent/will in (planner/executor/etc.), to have a solid working module put together? Are we looking at something like 4

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 10:03 AM, Heikki Linnakangas wrote: > On 20.09.2011 11:18, Simon Riggs wrote: >> >> The bgwriter avoids I/O, if it is operating correctly. This patch >> ensures it continues to operate even during heavy checkpoints. So it >> helps avoid extra I/O during a period of very hig

[HACKERS] MicrOLAP Database Designer with PostgreSQL 9.1 support is out!

Hello. Database Designer for PostgreSQL is an easy CASE tool which works natively under Windows OS family and Linux under Wine/WineHQ. This release introduces new functionality as well as several bug fixes. Support for PostgreSQL 9.1 added, new Create HTML Report functionality present, unlogged

Re: [HACKERS] WIP: Collecting statistics on CSV file data

Hi Fujita-san, (2011/09/12 19:40), Etsuro Fujita wrote: > Hi there, > > To enable file_fdw to estimate costs of scanning a CSV file more > accurately, I would like to propose a new FDW callback routine, > AnalyzeForeignTable, which allows to ANALYZE command to collect > statistics on a foreign ta

Re: [HACKERS] CUDA Sorting

On Sep19, 2011, at 19:46 , Stephen Frost wrote: > I agree that it'd be interesting to do, but I share Lord Stark's > feelings about the challenges and lack of potential gain- it's a very > small set of queries that would benefit from this. You need to be > working with enough data to make the cost

Re: [HACKERS] Separating bgwriter and checkpointer

On 20.09.2011 11:18, Simon Riggs wrote: The bgwriter avoids I/O, if it is operating correctly. This patch ensures it continues to operate even during heavy checkpoints. So it helps avoid extra I/O during a period of very high I/O activity. I don't see what difference it makes which process does

Re: [HACKERS] Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 9:06 AM, Heikki Linnakangas wrote: > On 20.09.2011 10:48, Simon Riggs wrote: >> >> On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masao >>  wrote: >>> >>> On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggs >>>  wrote: This patch splits bgwriter into 2 processes: checkpointer an

Re: [HACKERS] Separating bgwriter and checkpointer

On 20.09.2011 10:48, Simon Riggs wrote: On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masao wrote: On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggs wrote: This patch splits bgwriter into 2 processes: checkpointer and bgwriter, seeking to avoid contentious changes. Additional changes are expected in this

Re: [HACKERS] Separating bgwriter and checkpointer

On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masao wrote: > On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggs wrote: >> This patch splits bgwriter into 2 processes: checkpointer and >> bgwriter, seeking to avoid contentious changes. Additional changes are >> expected in this release to build upon these chan

Re: [HACKERS] File not found error on creating collation

On 20 September 2011 05:20, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane wrote: >>> We could possibly add a HINT suggesting that the locale isn't installed, >>> but I don't see that we could offer any useful generic advice about how >>> to install it.  I'm

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Fri, Sep 16, 2011 at 1:13 PM, Peter Eisentraut wrote: > On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote: >> As far as the other issues go, I think there is actually a >> prerequisite >> discussion to be had here, which is whether we are turning the >> recovery >> parameters into plain old GUC

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Fri, Sep 16, 2011 at 3:54 AM, Fujii Masao wrote: > On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane wrote: >> This seems like it's already predetermining the outcome of the argument >> about recovery.conf.  Mind you, I'm not unhappy with this choice, but >> it's hardly implementing only behavior tha

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Fri, Sep 16, 2011 at 2:46 PM, Euler Taveira de Oliveira wrote: > On 15-09-2011 23:54, Fujii Masao wrote: >> >> #1 >> Use empty recovery.ready file to enter arhicve recovery. recovery.conf >> is not read automatically. All recovery parameters are expected to be >> specified in postgresql.conf. I

Re: [HACKERS] Back-branch releases upcoming this week

On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane wrote: > As has been mentioned a couple times, we're well overdue for updates of > the back branches.  Seems like time to get that done, so we'll be > wrapping 8.2.x and up this Thursday for release Monday the 26th. 8.2 up, including 9.1.1? I'm not sure

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Fri, Sep 16, 2011 at 9:25 PM, Peter Eisentraut wrote: > On fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote: >> #1 >> Use empty recovery.ready file to enter arhicve recovery. recovery.conf >> is not read automatically. All recovery parameters are expected to be >> specified in postgresql.conf.