Re: [HACKERS] feature request: auto savepoint for interactive psql when in transaction.

2011-11-14 Thread Will Leinweber
My coworker Dan suggested that some people copy and paste scripts. However I feel that that is an orthogonal problem and if there is a very high rate of input psql should detect that and turn interactive off. And I still strongly feel that on_error_rollback=interactive should be the default. Until

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

2011-11-14 Thread Jaime Casanova
On Fri, Oct 7, 2011 at 10:10 AM, Julien Tachoires wrote: > Hi, > > Here's a patch to allow TOAST tables to be moved to a different tablespace. > This item has been picked up from the TODO list. > Main idea is to consider that a TOAST table can have its own tablespace. > Hi, This patch doesn't ap

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Greg Smith
On 11/14/2011 10:09 PM, Robert Haas wrote: I continue to think that we should be trying to sort these by subject matter. The term "core extensions" doesn't convey that these are server management and debugging tools, hence Josh's confusion. I'm not attached to the name, which I just pulled

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 8:44 PM, Greg Smith wrote: > On 11/14/2011 07:56 PM, Josh Berkus wrote: >> >> So I'm a bit unclear on why most of the optional data types were >> excluded from your list of Core Extensions. > > I was aiming for the extensions that seemed uncontroversial for a first pass > h

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

2011-11-14 Thread Steve Singer
On 11-10-31 12:11 AM, Jun Ishiduka wrote: >> >> Agreed. I'll extract FPW stuff from the patch that I submitted, and revise it >> as the infrastructure patch. >> >> The changes of pg_start_backup() etc that Ishiduka-san did are also >> a server-side infrastructure. I will extract them as another inf

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Greg Smith
On 11/14/2011 07:56 PM, Josh Berkus wrote: So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions. I was aiming for the extensions that seemed uncontroversial for a first pass here. One of the tests I applied was "do people sometimes need

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Peter Geoghegan
On 15 November 2011 00:56, Josh Berkus wrote: > So I'm a bit unclear on why most of the optional data types were > excluded from your list of Core Extensions.  I would regard the > following as stable and of general utility: > isn I consider contrib/isn to be quite broken. It hard codes ISBN pre

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Thom Brown
On 15 November 2011 00:56, Josh Berkus wrote: > Greg, > > So I'm a bit unclear on why most of the optional data types were > excluded from your list of Core Extensions.  I would regard the > following as stable and of general utility: > > btree_gin > btree_gist > citext > dblink > file_fdw > fuzzy

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Josh Berkus
Greg, So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions. I would regard the following as stable and of general utility: btree_gin btree_gist citext dblink file_fdw fuzzystrmatch hstore intarray isn ltree pgcrypto pg_trgm unaccent uuid-oss

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Josh Berkus
> This is a related problem, we should have a terminology for contrib > tools such as pg_standby or pg_archivecleanup, for modules like the one > you talk about, that provide new features but nothing visible from SQL, > and extensions, that are all about SQL --- and if I can work on my plans > wil

Re: [HACKERS] why do we need two snapshots per query?

2011-11-14 Thread Tatsuo Ishii
> On the other hand, if our goal in life is to promote the extended > query protocol over the simple query protocol at all costs, then I > agree that we shouldn't optimize the simple query protocol in any way. > Perhaps we should even post a big notice on it that says "this > facility is deprecate

[HACKERS] psql + libedit command history truncation (was: psql history vs. dearmor (pgcrypto))

2011-11-14 Thread Josh Kupershmidt
On Mon, Nov 14, 2011 at 1:01 PM, Robert Haas wrote: > It looks like the problem is that the original has a blank line after > the line that says "Version: GnuPG v2.0.17 (GNU/Linux)", but when you > recall it from the query buffer, that extra blank line gets elided. > > The attached patch fixes it

Re: [HACKERS] proposal: psql concise mode

2011-11-14 Thread Josh Kupershmidt
On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom wrote: > Concise output might look like (bikeshed argument: "splat" indicates > columns "squashed" out): > >  test=# \d+ foo >                          Table "public.foo" >  Column |  Type   # Storage # >  +-+-+ >  a      | in

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Andres Freund
On Monday, November 14, 2011 10:22:52 PM Tom Lane wrote: > "Kevin Grittner" writes: > >> Tom Lane wrote: > >>> Dunno ... where were the warnings exactly? > > > > From HEAD checkout of a few minutes ago I now see only 9: > Hmm ... well, none of those look likely to be in performance-sensitive > a

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Andres Freund
On Monday, November 14, 2011 10:25:19 PM Alvaro Herrera wrote: > Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011: > > Tom Lane wrote: > > > "Kevin Grittner" writes: > > >> Also, is there something I should do to deal with the warnings > > >> before this would be considere

Re: [HACKERS] feature request: auto savepoint for interactive psql when in transaction.

2011-11-14 Thread Ross Reedstrom
On Mon, Nov 14, 2011 at 02:45:04PM -0800, Will Leinweber wrote: > My coworker Dan suggested that some people copy and paste scripts. However > I feel that that is an orthogonal problem and if there is a very high rate > of input psql should detect that and turn interactive off. And I > still strong

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Martijn van Oosterhout
On Mon, Nov 14, 2011 at 06:25:19PM -0300, Alvaro Herrera wrote: > > All 10 were like this: > > > > warning: dereferencing type-punned pointer will break > > strict-aliasing rules > > Uhm, shouldn't we expect there to be one warning for each use of a Node > using some specific node pointer

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Bruce Momjian
Robert Haas wrote: > But Tom's point about XIDs and LSNs seems like it kind of puts a > bullet through the heart of the whole idea. Now, before you can move > the database (or table, or whatever) between clusters, you've got to > rewrite all the data files to freeze XIDs and, I don't know, zero ou

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Dimitri Fontaine
Thom Brown writes: > I'm all for removing all mention of "modules". It's ambiguous and > used inconsistently. The module is the shared library object. It should be possible to use that consistently. And I have some plans on my TODO list about them anyway, so making them disappear from the manu

Re: [HACKERS] feature request: auto savepoint for interactive psql when in transaction.

2011-11-14 Thread Ross Reedstrom
On Wed, Sep 28, 2011 at 11:47:51AM -0700, David Fetter wrote: > On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote: > > On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner > > wrote: > > > > > Alvaro Herrera wrote: > > > > > > > See ON_ERROR_ROLLBACK > > > > http://www.postgresql.org/docs

Re: [HACKERS] proposal: psql concise mode

2011-11-14 Thread Ross Reedstrom
On Mon, Nov 07, 2011 at 11:01:39PM -0500, Josh Kupershmidt wrote: > On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas wrote: > > >  I can also see myself turning it on and then going > > - oh, wait, is that column not there, or did it just disappear because > > I'm in concise mode? > > Yeah, that wou

Re: [HACKERS] Measuring relation free space

2011-11-14 Thread Jaime Casanova
On Wed, Nov 9, 2011 at 7:58 AM, Alvaro Herrera wrote: > > Excerpts from Jaime Casanova's message of mar nov 08 18:12:25 -0300 2011: >> On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander wrote: >> > >> > Looks pretty useful. >> >> thanks for the review, attached is a new version of it > > Note that A

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Thom Brown
On 14 November 2011 09:08, Greg Smith wrote: > I've revived the corpose of the patch submitted in May, now that it's a much > less strange time of the development cycle to consider it. >  http://archives.postgresql.org/message-id/4df048bd.8040...@2ndquadrant.com > was the first attempt to move som

Re: [HACKERS] why do we need two snapshots per query?

2011-11-14 Thread Robert Haas
On Nov 14, 2011, at 4:31 PM, Greg Smith wrote: > On 11/14/2011 04:04 PM, Robert Haas wrote: >> Some pgbench -S numbers (SELECT-only test) from Nate Boley's 32-core >> box > > It seems like Nate Boley's system should be be credited in the 9.2 release > notes. +1. Having access to that box h

Re: [HACKERS] why do we need two snapshots per query?

2011-11-14 Thread Greg Smith
On 11/14/2011 04:04 PM, Robert Haas wrote: Some pgbench -S numbers (SELECT-only test) from Nate Boley's 32-core box It seems like Nate Boley's system should be be credited in the 9.2 release notes. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training

Re: [HACKERS] Group Commit

2011-11-14 Thread Greg Smith
On 11/14/2011 03:43 PM, Josh Berkus wrote: Purpose is to provide consistent WAL writes, even when WALInsertLock contended. Currently no "off" option, thinking is that the overhead of doing this is relatively low and so it can be "always on" - exactly as it is for sync rep. Hmmm, have y

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Alvaro Herrera
Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011: > Tom Lane wrote: > > "Kevin Grittner" writes: > >> Also, is there something I should do to deal with the warnings > >> before this would be considered a meaningful test? > > > > Dunno ... where were the warnings exactly

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Tom Lane
"Kevin Grittner" writes: >> Tom Lane wrote: >>> Dunno ... where were the warnings exactly? > From HEAD checkout of a few minutes ago I now see only 9: Hmm ... well, none of those look likely to be in performance-sensitive areas. But I wonder just how good the trouble-detection code is these d

Re: [HACKERS] patch: CHECK FUNCTION statement

2011-11-14 Thread Thom Brown
On 14 November 2011 20:54, Pavel Stehule wrote: > Hello > > 2011/11/14 Thom Brown : >> On 6 October 2011 12:52, Pavel Stehule wrote: >>> >>> Hello >>> >>> I am sending a version with regress tests and basic documentation >> >> Hi Pavel, >> >> I think this sentence needs rewriting: >> >> "checkfun

Re: [HACKERS] why do we need two snapshots per query?

2011-11-14 Thread Robert Haas
On Sun, Nov 13, 2011 at 9:40 PM, Robert Haas wrote: > On Sun, Nov 13, 2011 at 8:57 PM, Robert Haas wrote: >> In the -M extended case, we take a snapshot from exec_parse_message(), >> and the same two in the exec_bind_message() call that are taken in the >> -M prepared case.  So reducing the prepa

Re: [HACKERS] patch: CHECK FUNCTION statement

2011-11-14 Thread Pavel Stehule
Hello 2011/11/14 Thom Brown : > On 6 October 2011 12:52, Pavel Stehule wrote: >> >> Hello >> >> I am sending a version with regress tests and basic documentation > > Hi Pavel, > > I think this sentence needs rewriting: > > "checkfunction is the name of a previously registered function that > will

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
"Kevin Grittner" wrote: > Tom Lane wrote: >> "Kevin Grittner" writes: >>> Also, is there something I should do to deal with the warnings >>> before this would be considered a meaningful test? >> >> Dunno ... where were the warnings exactly? > > All 10 were like this: > > warning: deref

Re: [HACKERS] Group Commit

2011-11-14 Thread Josh Berkus
> Purpose is to provide consistent WAL writes, even when WALInsertLock > contended. Currently no "off" option, thinking is that the overhead of > doing this is relatively low and so it can be "always on" - exactly as > it is for sync rep. Hmmm, have you had a chance to do any performance tests?

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Tom Lane wrote: > Dunno ... where were the warnings exactly? Ah, you asked "where", not "what". I don't think I saved that, and I had to reboot for a new kernel, so I don't have the buffer sitting around. I'll do a new build and let you know shortly. -Kevin -- Sent via pgsql-hackers mail

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Tom Lane wrote: > "Kevin Grittner" writes: >> The results were interesting. While the small overlap between >> samples from the two builds at most levels means that this was >> somewhat unlikely to be just sampling noise, there could have >> been alignment issues that account for some of the dif

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Tom Lane
"Kevin Grittner" writes: > The results were interesting. While the small overlap between > samples from the two builds at most levels means that this was > somewhat unlikely to be just sampling noise, there could have been > alignment issues that account for some of the differences. In > short,

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011: > >> Well, it looks to me like there are three different places that we >> need to nail down: RangeVarGetAndCheckCreationNamespace() is used for >> relations (except that

Re: [HACKERS] patch: CHECK FUNCTION statement

2011-11-14 Thread Thom Brown
On 6 October 2011 12:52, Pavel Stehule wrote: > > Hello > > I am sending a version with regress tests and basic documentation Hi Pavel, I think this sentence needs rewriting: "checkfunction is the name of a previously registered function that will be called when a new function in the language i

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Alvaro Herrera
Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011: > Well, it looks to me like there are three different places that we > need to nail down: RangeVarGetAndCheckCreationNamespace() is used for > relations (except that a few places call RangeVarGetCreationNamespace > directly, w

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Florian Pflug wrote: > If we're concerned about helping the compiler produce better code, > I think we should try to make our code safe under strict aliasing > rules. AFAIK, that generally helps much more than > const-correctness. (Dunno how feasible that is, though) To get a preliminary feel

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-14 Thread Erik Rijkers
On Mon, November 14, 2011 19:43, Tom Lane wrote: > Jeff Davis writes: >> On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote: > > While thinking about this ... would it be sensible for range_lower and > range_upper to return NULL instead of throwing an exception for empty or > infinite ranges? As w

Re: [HACKERS] So where are we on the open commitfest?

2011-11-14 Thread Greg Stark
On Mon, Nov 14, 2011 at 4:23 PM, Nikhil Sontakke wrote: >> > * Non-inheritable check constraints >> > > > So, this patch got shifted to the next commitfest... I'm sorry, I had intended to get to it for the last two weekends. I'm not going to wait until the commitfest to look at it. What I want

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 12:48 PM, Nikhil Sontakke wrote: >> So it's probably going to take a while to get this >> completely nailed down, but we can keep chipping away at it. > > Agreed. So are you planning to commit this change? Or we want some more > objects to be fixed? Last I looked at this, w

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-14 Thread Tom Lane
Jeff Davis writes: > On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote: >> It needs to return FALSE, actually. After further reading I realized >> that you have that behavior hard-wired into the range GiST routines, >> and it's silly to make the stand-alone versions of the function act >> differe

Re: [HACKERS] Syntax for partitioning

2011-11-14 Thread Martijn van Oosterhout
On Mon, Nov 14, 2011 at 10:33:36AM +0100, Dimitri Fontaine wrote: > Martijn van Oosterhout writes: > > While I agree that explicit partitioning is somewhat of a hack, it's a > > really useful hack. But for me the most important use of partitioning > > is "dropping a billion rows efficiently and g

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-14 Thread Jeff Davis
On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote: > It needs to return FALSE, actually. After further reading I realized > that you have that behavior hard-wired into the range GiST routines, > and it's silly to make the stand-alone versions of the function act > differently. Good point. That ma

Re: [HACKERS] psql history vs. dearmor (pgcrypto)

2011-11-14 Thread Robert Haas
2011/11/13 Tomas Vondra : > but recalling it from the query buffer results in > >  ERROR:  Corrupt ascii-armor > > I've noticed this on 9.1 but 9.2devel behaves exactly the same. I'm > using 64-bit Linux with UTF8, nothing special. It looks like the problem is that the original has a blank line af

[HACKERS] CommitFest 2011-11 starting soon

2011-11-14 Thread Greg Smith
Tomorrow November 15, patch submission will close for the 2011-11 CommitFest after 11:59PM PST. New patches ready for review should be submitted to this mailing list and added to the CommitFest application at https://commitfest.postgresql.org/ See http://wiki.postgresql.org/wiki/Development_i

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Nikhil Sontakke
> So it's probably going to take a while to get this > completely nailed down, but we can keep chipping away at it. > > Agreed. So are you planning to commit this change? Or we want some more objects to be fixed? Last I looked at this, we will need locking to be done while creating tables, views, t

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-14 Thread Robert Haas
On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane wrote: > While investigating bug #6291 I was somewhat surprised to discover > $SUBJECT.  The cause turns out to be this kluge in alter_table.sql: > >        select virtualtransaction >        from pg_locks >        where transactionid = txid_current()::int

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 11:48 AM, Nikhil Sontakke wrote: >> If all you need to do is lock a schema, you can just call >> LockDatabaseObject(NamespaceRelationId, namespace_oid, 0, >> AccessShareLock); there's no need to fake up an objectaddress just to >> take a lock.  But I think that's not really

Re: [HACKERS] [Feature Request] \dx show "options"

2011-11-14 Thread Emanuel Calvo
2011/11/14 Robert Haas : > On Mon, Nov 14, 2011 at 10:45 AM, Emanuel Calvo > wrote: >> 2011/11/10 Robert Haas : >>> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo >>> wrote: > \dew+ lists the actual options supplied to a foreign data wrapper already. Checked, but the options doesn

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

2011-11-14 Thread Nikhil Sontakke
> If all you need to do is lock a schema, you can just call > LockDatabaseObject(NamespaceRelationId, namespace_oid, 0, > AccessShareLock); there's no need to fake up an objectaddress just to > take a lock. But I think that's not really all you need to do, > because somebody could drop the namespa

Re: [HACKERS] So where are we on the open commitfest?

2011-11-14 Thread Nikhil Sontakke
> > * Non-inheritable check constraints > > > So, this patch got shifted to the next commitfest... Regards, Nikhils

Re: [HACKERS] star join optimization

2011-11-14 Thread Rudyar
On 14/11/11 13:09, Greg Smith wrote: On 11/14/2011 10:44 AM, Rudyar wrote: Ok, I'm working in that project. I will send you my results and comparision with SQL server HHJ optimization in one or two months. Please be careful not to share here details of how features like this are built in any

Re: [HACKERS] [Feature Request] \dx show "options"

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 10:45 AM, Emanuel Calvo wrote: > 2011/11/10 Robert Haas : >> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo >> wrote: \dew+ lists the actual options supplied to a foreign data wrapper already. >>> >>> Checked, but the options doesn't appear (the column exists, but is

Re: [HACKERS] star join optimization

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 8:25 AM, Rudyar wrote: > the hybrid hash join algorithm implemented in the current version of > PostgreSQL has any kind of optimization > for star join queries for Data Warehouse model? Not really. As much as possible, we try to make the query optimizer a general-purpose

Re: [HACKERS] star join optimization

2011-11-14 Thread Greg Smith
On 11/14/2011 10:44 AM, Rudyar wrote: Ok, I'm working in that project. I will send you my results and comparision with SQL server HHJ optimization in one or two months. Please be careful not to share here details of how features like this are built in any commercial databases you evaluate. So

Re: [HACKERS] [Feature Request] \dx show "options"

2011-11-14 Thread Emanuel Calvo
2011/11/10 Robert Haas : > On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo wrote: >>> \dew+ lists the actual options supplied to a foreign data wrapper already. >> >> Checked, but the options doesn't appear (the column exists, but is empty). > > Well, that just means that you didn't specify any opt

Re: [HACKERS] star join optimization

2011-11-14 Thread Rudyar
On 14/11/11 12:37, Robert Haas wrote: On Mon, Nov 14, 2011 at 10:36 AM, Rudyar wrote: On 14/11/11 12:20, Robert Haas wrote: On Mon, Nov 14, 2011 at 8:25 AM, Rudyarwrote: the hybrid hash join algorithm implemented in the current version of PostgreSQL has any kind of optimization for star j

Re: [HACKERS] star join optimization

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 10:36 AM, Rudyar wrote: > On 14/11/11 12:20, Robert Haas wrote: >> >> On Mon, Nov 14, 2011 at 8:25 AM, Rudyar  wrote: >>> >>> the hybrid hash join algorithm implemented in the current version of >>> PostgreSQL has any kind of optimization >>> for star join queries for Data

Re: [HACKERS] star join optimization

2011-11-14 Thread Rudyar
On 14/11/11 12:20, Robert Haas wrote: On Mon, Nov 14, 2011 at 8:25 AM, Rudyar wrote: the hybrid hash join algorithm implemented in the current version of PostgreSQL has any kind of optimization for star join queries for Data Warehouse model? Not really. As much as possible, we try to make the

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Thom Brown
On 14 November 2011 15:07, Robert Haas wrote: > On Mon, Nov 14, 2011 at 10:05 AM, Thom Brown wrote: > > On 14 November 2011 13:32, Robert Haas wrote: > >> > >> But Tom's point about XIDs and LSNs seems like it kind of puts a > >> bullet through the heart of the whole idea. > > > > What about ha

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 10:05 AM, Thom Brown wrote: > On 14 November 2011 13:32, Robert Haas wrote: >> >> But Tom's point about XIDs and LSNs seems like it kind of puts a >> bullet through the heart of the whole idea. > > What about having database-level XIDs rather than cluster-level?  Is that >

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Thom Brown
On 14 November 2011 13:32, Robert Haas wrote: > > But Tom's point about XIDs and LSNs seems like it kind of puts a > bullet through the heart of the whole idea. > What about having database-level XIDs rather than cluster-level? Is that remotely feasible? -- Thom Brown Twitter: @darkixion IRC (

Re: [HACKERS] [REVIEW] Patch for cursor calling with named parameters

2011-11-14 Thread Yeb Havinga
On 2011-10-15 07:41, Tom Lane wrote: Yeb Havinga writes: Hello Royce, Thanks again for testing. I looked this patch over but concluded that it's not ready to apply, mainly because there are too many weird behaviors around error reporting. Thanks again for the review and comments. Attached is

Re: [HACKERS] Working with git repo tagged versions

2011-11-14 Thread Peter Eisentraut
On fre, 2011-11-11 at 15:53 -0500, Bruce Momjian wrote: > Basically, git checkout assumes a tag, unless you -b for a branch. No, git checkout assumes a branch, and if it doesn't find a branch, it looks for a commit by the given name, and a tag is one way of naming a commit. The -b option creates

Re: [HACKERS] (PATCH) Adding CORRESPONDING to Set Operations

2011-11-14 Thread Kerem Kat
On Mon, Nov 14, 2011 at 15:32, Tom Lane wrote: > Kerem Kat writes: >> Corresponding is currently implemented in the parse/analyze phase. If >> it were to be implemented in the planning phase, explain output would >> likely be as you expect it to be. > > It's already been pointed out to you that d

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 4:55 AM, Thom Brown wrote: > So can I humbly request we completely re-architect the whole of > PostgreSQL to fit this feature?  Thanks. Heh. I have to admit I've thought about this from time to time, and it would be pretty cool. I was initially thinking that it wouldn't

Re: [HACKERS] (PATCH) Adding CORRESPONDING to Set Operations

2011-11-14 Thread Tom Lane
Kerem Kat writes: > Corresponding is currently implemented in the parse/analyze phase. If > it were to be implemented in the planning phase, explain output would > likely be as you expect it to be. It's already been pointed out to you that doing this at parse time is unacceptable, because of the

[HACKERS] star join optimization

2011-11-14 Thread Rudyar
Hello, the hybrid hash join algorithm implemented in the current version of PostgreSQL has any kind of optimization for star join queries for Data Warehouse model? Regards. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.

Re: [HACKERS] (PATCH) Adding CORRESPONDING to Set Operations

2011-11-14 Thread Thom Brown
On 14 November 2011 11:29, Kerem Kat wrote: > > This explain plan doesn't look right to me: > > > > test=# explain select a,b,c from one intersect corresponding by (a,c) > > select a,b,c from two; > > QUERY PLAN > > > -

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-14 Thread Tom Lane
Jeff Davis writes: > On Sun, 2011-11-13 at 15:38 -0500, Tom Lane wrote: >> I think this demonstrates that the current definition of range_before is >> broken. It is not reasonable for it to throw an error on a perfectly >> valid input ... at least, not unless you'd like to mark it VOLATILE so >>

Re: [HACKERS] FDW system columns

2011-11-14 Thread Thom Brown
2011/11/14 Shigeru Hanada > (2011/11/14 11:25), Robert Haas wrote: > > My vote is to nuke 'em all. :-) > > +1. > > IIRC, main purpose of supporting tableoid for foreign tables was to be > basis of foreign table inheritance, which was not included in 9.1, and > we have not supported it yet. Othe

Re: [HACKERS] FDW system columns

2011-11-14 Thread Shigeru Hanada
(2011/11/14 11:25), Robert Haas wrote: > My vote is to nuke 'em all. :-) +1. IIRC, main purpose of supporting tableoid for foreign tables was to be basis of foreign table inheritance, which was not included in 9.1, and we have not supported it yet. Other system columns are essentially garbage,

Re: [HACKERS] (PATCH) Adding CORRESPONDING to Set Operations

2011-11-14 Thread Kerem Kat
> This explain plan doesn't look right to me: > > test=# explain select a,b,c from one intersect corresponding by (a,c) > select a,b,c from two; >                                   QUERY PLAN > - >  HashSetOp Intersect

Re: [HACKERS] (PATCH) Adding CORRESPONDING to Set Operations

2011-11-14 Thread Thom Brown
On 25 October 2011 18:49, Kerem Kat wrote: > On Mon, Oct 24, 2011 at 20:52, Erik Rijkers wrote: >> On Wed, October 19, 2011 15:01, Kerem Kat wrote: >>> Adding CORRESPONDING to Set Operations >>> Initial patch, filename: corresponding_clause_v2.patch >> >> I had a quick look at the behaviour of th

[HACKERS] Group Commit

2011-11-14 Thread Simon Riggs
Enclosed patch implements Group Commit and also powersave mode for WALWriter. XLogFlush() waits for WALWriter to run XLogBackgroundFlush(), which flushes WAL and then wakes waiters. Uses same concepts and similar code to sync rep. Purpose is to provide consistent WAL writes, even when WALInsertLo

Re: [HACKERS] Detach/attach database

2011-11-14 Thread Thom Brown
On 13 November 2011 15:26, Simon Riggs wrote: > On Sun, Nov 13, 2011 at 1:13 PM, Thom Brown wrote: > >> I don't know if this has been discussed before, but would it be >> feasible to introduce the ability to detach and attach databases? (if >> you're thinking "stop right there" skip to the end)  

Re: [HACKERS] Syntax for partitioning

2011-11-14 Thread Dimitri Fontaine
Martijn van Oosterhout writes: > While I agree that explicit partitioning is somewhat of a hack, it's a > really useful hack. But for me the most important use of partitioning > is "dropping a billion rows efficiently and getting the disk space > back". And the biggest problem is always that dro

Re: [HACKERS] Syntax for partitioning

2011-11-14 Thread Dimitri Fontaine
Tom Lane writes: > to match the desired granularity of data removal. I don't really see > any way that the database can be expected to know what that is, unless > it's told in advance. So AFAICS you really have to have a declarative > way of telling it how to do the partitioning --- it's not goi

Re: [HACKERS] SQLDA fix for ECPG

2011-11-14 Thread Boszormenyi Zoltan
2011-11-13 17:27 keltezéssel, Tom Lane írta: > Boszormenyi Zoltan writes: >> I had a report about ECPG code crashing which involved >> a query using a date field. Attached is a one liner fix to make >> the date type's offset computed consistently across >> sqlda_common_total_size(), sqlda_compat_t