Re: [HACKERS] Accounting for toast in query planner. (gin/gist indexes).

jes...@krogh.cc writes: > Secondly I could bump the default cost of ts_match_vq/ts_match_qv a > bit up, since the cost of doing that computation is probably not as > cheap as a ordinary boolean function. Actually, you could try bumping their costs up by more than "a bit". It's a tad unfair to blam

Re: [HACKERS] Inlining comparators as a performance optimisation

Robert Haas writes: > On Thu, Dec 1, 2011 at 10:48 PM, Tom Lane wrote: >> I am thinking that the btree code, at least, would want to just >> unconditionally do >> >>colsortinfo->comparator(datum1, datum2, colsortinfo) >> >> so for an opclass that fails to supply the low-overhead compara

Re: [HACKERS] Inlining comparators as a performance optimisation

On Thu, Dec 1, 2011 at 10:48 PM, Tom Lane wrote: > But you still need a lot of mechanism to do that mapping, including an > initialization function that has noplace to be executed (unless every > .so that defines a btree opclass has to be listed in preload_libraries), > so it doesn't seem like the

Re: [HACKERS] Inlining comparators as a performance optimisation

Robert Haas writes: > On Thu, Dec 1, 2011 at 9:46 PM, Tom Lane wrote: >> Nor does the "register a pointer" scheme you suggest make >> any sense to me: you still need to connect these things to catalog >> entries, pg_opclass entries in particular, and the intermediate handle >> adds nothing to the

Re: [HACKERS] Inlining comparators as a performance optimisation

On Thu, Dec 1, 2011 at 9:46 PM, Tom Lane wrote: > IMO, entries in pg_proc ought to refer to functions that are callable > by the standard interface: breaking that basic contract is not going to > lead anywhere pleasant.  Nor do I really want yet more columns in > pg_proc. I wasn't proposing to cr

Re: [HACKERS] Why so few built-in range types?

Robert Haas writes: > On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote: >> I don't have any particular care about if cidr has indexing support or >> not. I'm certainly not *against* it, except insofar as it encourages >> use of a data type that really could probably be better (by being more >

Re: [HACKERS] Inlining comparators as a performance optimisation

Robert Haas writes: > On Thu, Dec 1, 2011 at 8:13 PM, Tom Lane wrote: >> What I want to see is some mechanism that pushes this out to the >> individual datatypes, so that both core and plug-in datatypes have >> access to the benefits. There are a number of ways that could be >> attacked, but the

Re: [HACKERS] Why so few built-in range types?

On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote: > I don't have any particular care about if cidr has indexing support or > not.  I'm certainly not *against* it, except insofar as it encourages > use of a data type that really could probably be better (by being more > like ip4r..). Not that y

Re: [HACKERS] Inlining comparators as a performance optimisation

On Thu, Dec 1, 2011 at 8:13 PM, Tom Lane wrote: > What I want to see is some mechanism that pushes this out to the > individual datatypes, so that both core and plug-in datatypes have > access to the benefits.  There are a number of ways that could be > attacked, but the most obvious one is to inv

Re: [HACKERS] Command Triggers

Andres Freund writes: > On Thursday, December 01, 2011 07:21:25 PM Tom Lane wrote: >> Making this work cleanly would be a bigger deal than I think you're >> thinking. > Obviously that depends on the definition of clean... > Changing the grammar to make that explicit seems to involve a bit too ma

Re: [HACKERS] Inlining comparators as a performance optimisation

On Thu, Dec 1, 2011 at 8:29 PM, Peter Geoghegan wrote: > Do your usual compile options include debug symbols? I've been using > standard compile options for development of this patch, for obvious > reasons. I get 36690 bytes (just under 36 KiB, or a 0.644% increase). They do, but I ran "strip" on

Re: [HACKERS] Inlining comparators as a performance optimisation

On 1 December 2011 17:15, Robert Haas wrote: > One thing I'm starting to get a bit concerned about is the effect of > this patch on the size of the resulting binary.  The performance > results you've posted are getting steadily more impressive as you get > into this, which is cool, but it seems li

Re: [HACKERS] Inlining comparators as a performance optimisation

Robert Haas writes: > On Thu, Dec 1, 2011 at 11:44 AM, Peter Geoghegan > wrote: >> Attached is revision of my patch with some clean-ups. > One thing I'm starting to get a bit concerned about is the effect of > this patch on the size of the resulting binary. Regardless of that, I'm still of the

Re: [HACKERS] Why so few built-in range types?

* Robert Haas (robertmh...@gmail.com) wrote: > Me neither. The ip4r type also supports ranges that aren't on > CIDR-block boundaries, which probably isn't something that makes sense > to incorporate into cidr. But not everyone needs that, and some > people might also need support for ipv6 CIDR bl

Re: [HACKERS] backup_label during crash recovery: do we know how to solve it?

On Tue, Nov 29, 2011 at 9:10 PM, Daniel Farina wrote: > Reviving a thread that has hit its second birthday: > > http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php > > In our case not being able to restart Postgres when it has been taken > down in the middle of a base backup is start

Re: [HACKERS] Postgresql 9.1 replication failing

Hello Jim, I think you not have other possibilities if the archives are corrupted and there are no possibilities to restore it, you need to recreate the standby starting from a base backup. Kind Regards 2011/12/1 Jim Buttafuoco > Simon, > > What do you mean, start over with a ba

Re: [HACKERS] to_date() marked stable?

>> Are there people using to_date in indexes or partition functions where >> changing it to immutable would be useful? I do, but I also create a shell function which sets timezone etc. locally so that to_date is *really* immutable. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com --

Re: [HACKERS] TupleDescInitEntry failing to initialize varlen members

Alvaro Herrera writes: > I just noticed in gdb that TupleDescInitEntry does not initialize > attacl, attoptions, attfdwoptions. Indeed not, because it's not building a tuple. It's building an array of C structs, and there's nothing useful to do with those fields. (Robert's proposal to not even

Re: [HACKERS] patch for type privileges

On mån, 2011-11-28 at 14:25 -0600, Merlin Moncure wrote: > On Tue, Nov 15, 2011 at 2:23 PM, Peter Eisentraut wrote: > > The basics here are mainly informed by the SQL standard. One thing from > > there I did not implement is checking for permission of a type used in > > CAST (foo AS type). This

Re: [HACKERS] patch for type privileges

On tor, 2011-12-01 at 14:37 +0100, Yeb Havinga wrote: > On 2011-11-29 18:47, Peter Eisentraut wrote: > > On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote: > >> On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote: > >>> On 2011-11-15 21:50, Peter Eisentraut wrote: > Patch attached. >

Re: [HACKERS] Postgresql 9.1 replication failing

Simon,What do you mean, start over with a base backup?JimOn Dec 1, 2011, at 4:08 PM, Simon Riggs wrote:On Thu, Dec 1, 2011 at 7:09 PM, Jim Buttafuoco wrote: the WAL file on the master is long gone, how would one inspect the web segment?  Any way to have PG "move" on?Regene

[HACKERS] TupleDescInitEntry failing to initialize varlen members

Hi, I just noticed in gdb that TupleDescInitEntry does not initialize attacl, attoptions, attfdwoptions. This is probably not very serious (otherwise we'd have bugs about it), but it is noticeable in tupdescs constructed by the executor, at least ExecTypeFromTL: (gdb) print *tupDesc->attrs[2] $

Re: [HACKERS] Postgresql 9.1 replication failing

On Thu, Dec 1, 2011 at 9:08 PM, Simon Riggs wrote: > On Thu, Dec 1, 2011 at 7:09 PM, Jim Buttafuoco > wrote: >> >> the WAL file on the master is long gone, how would one inspect the web >> segment?  Any way to have PG "move" on? > > > Regenerate the master. typo: regenerate *from* the master --

Re: [HACKERS] Postgresql 9.1 replication failing

On Thu, Dec 1, 2011 at 7:09 PM, Jim Buttafuoco wrote: > the WAL file on the master is long gone, how would one inspect the web > segment? Any way to have PG "move" on? > Regenerate the master. > -- > Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Supp

Re: [HACKERS] Command Triggers

On Sat, Nov 26, 2011 at 7:20 PM, Dimitri Fontaine wrote: > FWIW (scheduling mainly), I don't think I'm going to spend more time on > this work until I get some comments, because all that remains to be done > is about building on top of what I've already been doing here. +1 overall One of the m

Re: [HACKERS] Command Triggers

On Thursday, December 01, 2011 07:21:25 PM Tom Lane wrote: > Well, I think the main problem is going to be shunting the query down > the right parsing track (SELECT versus utility-statement) early enough. > Making this work cleanly would be a bigger deal than I think you're > thinking. Obviously th

Re: [HACKERS] Command Triggers

On Thursday, December 01, 2011 07:21:25 PM Tom Lane wrote: > Andres Freund writes: > > On Tuesday, November 08, 2011 06:47:13 PM Dimitri Fontaine wrote: > >> exception to that rule would be SELECT INTO and CREATE TABLE AS SELECT, > >> and my proposal would be to add specific call sites to the func

Re: [HACKERS] Postgresql 9.1 replication failing

the WAL file on the master is long gone, how would one inspect the web segment?  Any way to have PG "move" on?On Dec 1, 2011, at 2:02 PM, Jerry Sievers wrote:Jim Buttafuoco writes:All,I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping.  I had

Re: [HACKERS] Postgresql 9.1 replication failing

Jim Buttafuoco writes: > All, > > I have a large PG 9.1.1 server (over 1TB of data) and replica using log > shipping. I had some hardware issues on the > replica system and now I am getting the following in my pg_log/* files. Same > 2 lines over and over since yesterday. > > 2011-12-01 07:46:

Re: [HACKERS] Postgresql 9.1 replication failing

On Thu, Dec 1, 2011 at 1:41 PM, Jim Buttafuoco wrote: > 2011-12-01 07:46:30 EST  >LOG:  restored log file "0001028E00E5" > from archive > 2011-12-01 07:46:30 EST  >LOG:  incorrect resource manager data checksum in > record at 28E/E555E1B8 > > Anything I can do on the replica or do I

[HACKERS] Postgresql 9.1 replication failing

All,I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping.  I had some hardware issues on the replica system and now I am getting the following in my pg_log/* files.  Same 2 lines over and over since yesterday.2011-12-01 07:46:30 EST  >LOG:  restored log file "0001000

Re: [HACKERS] Command Triggers

Andres Freund writes: > On Tuesday, November 08, 2011 06:47:13 PM Dimitri Fontaine wrote: >> exception to that rule would be SELECT INTO and CREATE TABLE AS SELECT, >> and my proposal would be to add specific call sites to the functions >> I've provided in the attached patch rather than try to con

Re: [HACKERS] Command Triggers

Hi, On Tuesday, November 08, 2011 06:47:13 PM Dimitri Fontaine wrote: > exception to that rule would be SELECT INTO and CREATE TABLE AS SELECT, > and my proposal would be to add specific call sites to the functions > I've provided in the attached patch rather than try to contort them into > being

Re: [HACKERS] FlexLocks

On Wed, Nov 30, 2011 at 7:01 PM, Kevin Grittner wrote: > "Kevin Grittner" wrote: > >> OK.  There are a few things I found in this pass which missed in the >> last.  One contrib module was missed, I found another typo in a >> comment, and I think we can reduce the include files a bit.  Rather >> t

Re: [HACKERS] Why so few built-in range types?

On Thu, Dec 1, 2011 at 9:12 AM, wrote: > I do not think that adding index support to a datatype classifies as > semantic > change that will break backward compatibility. Me neither. The ip4r type also supports ranges that aren't on CIDR-block boundaries, which probably isn't something that make

Re: [HACKERS] Inlining comparators as a performance optimisation

On Thu, Dec 1, 2011 at 11:44 AM, Peter Geoghegan wrote: > Attached is revision of my patch with some clean-ups. In particular, > I'm now using switch statements for greater readability, plus > supporting fast path sorting of the time datatype. I've also updated > the documentation on "Date/Time Ty

Re: [HACKERS] Add minor version to v3 protocol to allow changes without breaking backwards compatibility

On Thu, Dec 1, 2011 at 8:42 AM, Mikko Tiihonen wrote: > On 11/30/2011 06:52 PM, Merlin Moncure wrote: >> >> On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen >>  wrote: >>> >>> Hi, >>> >>> As discussed few days ago it would be beneficial if we could change the >>> v3 >>> backend<->client protocol w

Re: [HACKERS] synchronous commit vs. hint bits

On Thu, Dec 1, 2011 at 9:58 AM, Jeff Janes wrote: > Waiting until the other one completes is how it currently is > implemented, but is it necessary from a correctness view?  It seems > like the WALWriteLock only needs to protect the write, and not the > sync (assuming the sync method allows those

Re: [HACKERS] Inlining comparators as a performance optimisation

Attached is revision of my patch with some clean-ups. In particular, I'm now using switch statements for greater readability, plus supporting fast path sorting of the time datatype. I've also updated the documentation on "Date/Time Types" to note the additional disadvantage of using the deprecated

Re: [HACKERS] Command Triggers

Hi Dimitri, Hi all, On Tuesday, November 08, 2011 06:47:13 PM Dimitri Fontaine wrote: > As proposed by Jan Wieck on hackers and discussed in Ottawa at the > Clusters Hackers Meeting, the most (only?) workable way to ever have DDL > triggers is to have "command triggers" instead. > Rather than talk

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 11/27/2011 09:18 AM, NISHIYAMA Tomoaki wrote: Hi, +/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by + * mingw-w64, however it gots defined only after Why not use __MINGW32__, which is defined without including any headers? Because it's defined by other than mingw-w6

Re: [HACKERS] synchronous commit vs. hint bits

On Thu, Dec 1, 2011 at 6:11 AM, Robert Haas wrote: > > One possible downside of trying to kick off the fsync more quickly is > that if there are a continuous stream of background fsyncs going on, a > process that needs to do an XLogFlush in the foreground (i.e. a > synchronous_commit=on transactio

Re: [HACKERS] Add minor version to v3 protocol to allow changes without breaking backwards compatibility

On 11/30/2011 06:52 PM, Merlin Moncure wrote: On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen wrote: Hi, As discussed few days ago it would be beneficial if we could change the v3 backend<->client protocol without breaking backwards compatibility. Here is a working patch that exports a suppo

Re: [HACKERS] synchronous commit vs. hint bits

On Thursday, December 01, 2011 03:11:43 PM Robert Haas wrote: > On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund wrote: > >> Oh, that's interesting. Why do you want to avoid frequent fsyncs? I > >> thought the point of synchronous_commit=off was to move the fsyncs to > >> the background, but not ne

Re: [HACKERS] Why so few built-in range types?

- Цитат от Stephen Frost (sfr...@snowman.net), на 01.12.2011 в 15:56 - > * Robert Haas (robertmh...@gmail.com) wrote: >> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote: >> > Erm, isn't there a contrib type that already does all that for you..? >> > ip4r or whatever?  Just saying, if

Re: [HACKERS] synchronous commit vs. hint bits

On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund wrote: >> Oh, that's interesting.  Why do you want to avoid frequent fsyncs?  I >> thought the point of synchronous_commit=off was to move the fsyncs to >> the background, but not necessarily to decrease the frequency. > Is that so? If it wouldn't avoi

Re: [HACKERS] Why so few built-in range types?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote: > > Erm, isn't there a contrib type that already does all that for you..? > > ip4r or whatever?  Just saying, if you're looking for that capability.. > > Oh, huh, good to know. Still, I'm not sur

Re: [HACKERS] patch for type privileges

On 2011-11-29 18:47, Peter Eisentraut wrote: On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote: On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote: On 2011-11-15 21:50, Peter Eisentraut wrote: Patch attached. I cannot get the patch to apply, this is the output of patch -p1 --dry-run

Re: [HACKERS] WIP: index support for regexp search

On Thu, Dec 1, 2011 at 12:29 AM, Robert Haas wrote: > Please add this patch here so it does not get lost in the shuffle: > > https://commitfest.postgresql.org/action/commitfest_view/open Done. -- With best regards, Alexander Korotkov.

Re: [HACKERS] Inverse convertion for pg_mb2wchar

On Thu, Dec 1, 2011 at 12:30 AM, Robert Haas wrote: > On Mon, Nov 21, 2011 at 11:49 AM, Alexander Korotkov > wrote: > > I've a question about pg_mb2wchar function. Is there any way for inverse > > convertion pg_wchar* to char*? > > I've looked to pg_wchar_tbl table definition, and I didn't find

Re: [HACKERS] Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

2011/11/30 Robert Haas : > On Sun, Nov 27, 2011 at 3:14 PM, Kohei KaiGai wrote: >> If we add new properties that required by AlterObjectNamespace, as >> you suggested, it will allow to reduce number of caller of this routine >> mechanically with small changes. >> Should I try this reworking with t

Re: [HACKERS] Patch to allow users to kill their own queries

On 11/16/2011 01:28 PM, Daniel Farina wrote: As it would turn out, a patch for this has already been submitted: http://archives.postgresql.org/pgsql-hackers/2011-10/msg1.php There was some wrangling on whether it needs to be extended to be useful, but for our purposes the formulation already

Re: [HACKERS] [PATCH] optional cleaning queries stored in pg_stat_statements

On 11/25/2011 10:52 AM, Jeff Janes wrote: Given Peter's patch on the same subject, should we now mark this one as rejected in the commitfest app? https://commitfest.postgresql.org/action/patch_view?id=681 That may be premature. While the testing I've done so far suggests Peter's idea is the b

Re: [HACKERS] Allow substitute allocators for PGresult.

Ouch! I'm sorry for making a reverse patch for the first modification. This is an amendment of the message below. The body text is copied into this message. http://archives.postgresql.org/message-id/20111201.192419.103527179.horiguchi.kyot...@oss.ntt.co.jp === Hello, This is the next version

Re: [HACKERS] Allow substitute allocators for PGresult.

Hello, This is the next version of Allow substitute allocators for PGresult. Totally chaning the concept from the previous one, this patch allows libpq to handle alternative tuple store for received tuples. Design guidelines are shown below. - No need to modify existing client code of libpq.

Re: [HACKERS] Allow substitute allocators for PGresult.

Hello, me> I'll put further thought into dblink-plus taking it into me> account. .. me> Please let me have a little more time. I've inquired the developer of dblink-plus about RegisterResourceReleaseCallback(). He said that the function is in bad compatibility with current implementation. In add

Re: [HACKERS] Accounting for toast in query planner. (gin/gist indexes).

> Jesper Krogh writes: >> I have currently hit a problem which I dug into finding the cause for, >> in >> particular, searching in GIN indices seems in some situations to >> un-fairly favor Sequential Scans. > >> Googling a bit I found this page: >> http://postgis.refractions.net/docs/ch06.html#id

Re: [HACKERS] synchronous commit vs. hint bits

Hi Robert, On Wednesday, November 30, 2011 02:10:00 PM Robert Haas wrote: > On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi > > wrote: > >> Yes, I would expect that. What kind of increase are you seeing? Is > >> it causing a problem for you, or are you just making an observation? > > > > i

Re: [HACKERS] synchronous commit vs. hint bits

hi, > On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi > wrote: >>> Yes, I would expect that. What kind of increase are you seeing? Is >>> it causing a problem for you, or are you just making an observation? >> >> i was curious because my application uses async commits mainly to >> avoid frequ