2010/12/29 Dimitri Fontaine
> Please have a look at getddl:
>
> https://github.com/dimitri/getddl
>
>
Nice! Looks like a nifty tool.
When I tried it, "./getddl.py -f -F /crypt/funcs -d glue", I got the error
"No such file or directory: 'sql/schemas.sql'".
While the task of splitting objects int
Marko Tiikkaja wrote:
I have no idea why it worked in the past, but the patch was never
designed to work for UPSERT. This has been discussed in the past and
some people thought that that's not a huge deal.
It takes an excessively large lock when doing UPSERT, which means its
performance unde
Here's another attempt to reduce the number of places in the code that
need to be updated when adding a new relkind. It adds a few macros --
RELKIND_HAS_STORAGE(), RELKIND_HAS_SYSTEM_ATTS(), and
RELKIND_HAS_SYSTEM_GENERATED_ATTNAMES() and uses them in place of more
ad-hoc tests for the same condit
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
>> On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
>> > Perhaps. ?A few kooky rows is indeed common, but we're talking about a
>> > specific
>> > breed of kookiness: 99.9% of the
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
> > Perhaps. ?A few kooky rows is indeed common, but we're talking about a
> > specific
> > breed of kookiness: 99.9% of the rows have identical bits after an ALTER
> > TYPE
> > tran
We haven't seen any updated patches in a long, long time...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wed, Dec 29, 2010 at 9:45 PM, Marko Tiikkaja
wrote:
> I have no idea why it worked in the past, but the patch was never designed
> to work for UPSERT. This has been discussed in the past and some people
> thought that that's not a huge deal.
I think it's expected to fail in some *concurrent*
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
>> I think this scenario will be more common than you might think. Tables
>> don't contain random data; they contain data that the DBA thinks is valid.
>> The situation where the data is mostly as you expect but with a few kooky
>> rows is, i
On Wed, Dec 29, 2010 at 3:58 PM, Simon Riggs wrote:
> On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs
> wrote:
> > >> It's not a bug, that's the way it currently works. We don't need a
> test
> > >> case for that.
> >
On 2010-12-30 4:39 AM +0200, Greg Smith wrote:
And that got me back again to concurrent testing.
Moving onto next two problems...the basic MERGE feature seems to have
stepped backwards a bit too. I'm now seeing these quite often:
ERROR: duplicate key value violates unique constraint
"pgbench_
Marko Tiikkaja wrote:
As far as I can tell, this should work. I played around with the
patch and the problem seems to be the VALUES:
INTO Stock t
USING (SELECT 30, 2000) AS s(item_id,balance)
ON s.item_id=t.item_id
WHEN MATCHED THEN UPDATE SET balance=t.balance + s.balance
WHEN NOT MATCHED
(2010/12/30 9:34), Simon Riggs wrote:
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become v
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
> > What happens if someone alters the configuration so that the sepgsql
> > plugin is no longer installed. Does the hidden data become visible?
> >
> Yes. If sepgsql plugin is uninstalled, the hidden data become visible.
> But no matter. Sinc
We have been seeing these warnings recently whenever a standby is
brought up (typically to check it is ok). Sometimes they are coupled
with corrupted indexes which require a REINDEX to fix. Initially I
thought these uninitialized pages were due to primary crashes or
hardware issues, however I'v
On Wed, Dec 29, 2010 at 02:01:28PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
> >> I really really dislike the notion of a "verification scan": it's
> >> basically work that is going to be useless if it fails.
>
> > I think it has potential in
(2010/12/27 17:53), Simon Riggs wrote:
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> > some
> > cases, we can determine that doing so is unhelpful, and that the conversion
> > shall always succeed:
> > I wish to replace ta
On Wed, Dec 29, 2010 at 3:34 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Vaibhav Kaushal wrote:
> > > On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
> > > > On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> > > > > An quicksort method in
> > > > > sequential disk its just awful to be t
> Well, but that's not 7%, thats 7x! And the theorem says 'greater or equal'
> so this is actually the minimum - you can get a much bigger difference
> with lower probability. So you can easily get an estimate that is a few
> orders off.
FWIW, based on query performance, estimates which are up to
Attached is a small patch to avoid putting an opaque structure into
the slru.h file and using it in an external function call where
external callers must always specify NULL.
-Kevin
*** a/src/backend/access/transam/clog.c
--- b/src/backend/access/transam/clog.c
***
*** 445,451
On Wed, Dec 29, 2010 at 10:56:39AM -0500, Robert Haas wrote:
> On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
> > Having thought on it
> > more, though, it actually seems best to attempt the verification scan
> > *every*
> > time. In most ineligible conversions, an inequality will appear very
>
On 30.12.2010 00:19, Robert Treat wrote:
Howdy,
I am hoping someone can help me better understand what the "minimum recovery
ending location" of pg_controldata represents with regards to 9.0 hot
standbys. When I look at any of our 8.4 (or lower) installs this number is
almost always somewhere in
Howdy,
I am hoping someone can help me better understand what the "minimum recovery
ending location" of pg_controldata represents with regards to 9.0 hot
standbys. When I look at any of our 8.4 (or lower) installs this number is
almost always somewhere in the past of the xlog timeline (presuming t
On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote:
> On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
> wrote:
> > On 29.12.2010 06:54, Robert Haas wrote:
> >>
> >> With the patch:
> >>
> >> rhaas=# cluster v;
> >> ERROR: views do not support CLUSTER
> >
> > "do not support" sounds
Robert Haas writes:
> On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane wrote:
>> We had a long discussion upthread of what version numbers to keep where.
>> IMHO the Makefile is about the *least* useful place to put a version
>> number; the more so if you want more than one. What we seem to need is
>>
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
wrote:
> On 29.12.2010 06:54, Robert Haas wrote:
>>
>> With the patch:
>>
>> rhaas=# cluster v;
>> ERROR: views do not support CLUSTER
>
> "do not support" sounds like a missing feature, rather than a nonsensical
> command. How about something
On Dec 29, 2010, at 1:27 PM, Robert Haas wrote:
> I think there are really two tasks here:
>
> 1. Identify whether a newer set of SQL definitions than the one
> installed is available. If so, the extension is a candidate for an
> upgrade.
>
> 2. Identify whether the installed version of the SQL
Magnus Hagander writes:
>>> Would people be interested in putting pg_streamrecv
>>> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
>>> 9.1? I think it would make sense to do so.
+1 for having that in core, only available for the roles WITH
REPLICATION I suppose?
>> I think t
On Tue, Dec 28, 2010 at 07:09:14AM -0500, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 12:45 AM, David Fetter wrote:
> > I don't see how people can be relying on links to 9.1-to-be's
> > documentation.
>
> Well, it's always handy when the filenames are the same across
> versions. Ever looked at
On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Oleg Bartunov wrote:
>>> it's clear we need versions, probably, major.minor would be enough. The
>>> problem
>>> I see is how to keep .so in sync with .sql ? Should we store .sql in
>>> database ?
>
>> Don't people norm
Magnus Hagander writes:
> On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
>> Although maybe now that we've made recovery.conf use the GUC lexer we
>>oughta continue in that vein and expose those parameters as
>>PGC_INTERNAL GUCs rather than inventing a new function for it...
>
> That's definite
On Wed, Dec 29, 2010 at 3:01 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
>>> In practice I think it would make sense if heap_open accepts all
>>> relation types on which you can potentially do either a heapscan or
>>> indexsc
On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
> >> It's not a bug, that's the way it currently works. We don't need a test
> >> case for that.
>
> > Oh, you're right. I missed the fact that it's a left join.
>
>
"Kevin Grittner" wrote:
> if a serializable transaction which is not flagged as read only
> remains open long enough for over a billion other transactions to
> commit
Maybe a clarification and example would be useful. We're talking
about going through a billion transactions which were assigne
On Dec 29, 2010, at 12:23 PM, Tom Lane wrote:
> We had a long discussion upthread of what version numbers to keep where.
> IMHO the Makefile is about the *least* useful place to put a version
> number; the more so if you want more than one. What we seem to need is
> a version number in the .sql f
Bruce Momjian wrote:
> Vaibhav Kaushal wrote:
> > On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
> > > On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> > > > An quicksort method in
> > > > sequential disk its just awful to be thinking in a non SSD world, but
> > > > its possible in an SSD.
> >
Joel Jacobson writes:
> Solution: I propose a new option to pg_dump, --split, which dumps each
> object to a separate file in a user friendly directory structure:
Please have a look at getddl:
https://github.com/dimitri/getddl
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL
Josh Berkus writes:
> On 12/27/10 7:35 PM, Josh Berkus wrote:
>> On 12/27/10 1:45 PM, Peter Eisentraut wrote:
>>> I'm unable to produce any really "exciting" release notes for alpha3. I
>>> have produced a draft here:
>>> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
>>>
Bruce Momjian writes:
> Oleg Bartunov wrote:
>> it's clear we need versions, probably, major.minor would be enough. The
>> problem
>> I see is how to keep .so in sync with .sql ? Should we store .sql in
>> database ?
> Don't people normally define the version number in the Makefile and pass
> t
Alvaro Herrera wrote:
> If these limitations become a problem, you can always change them.
> A couple of zeroes at the start of the pg_clog filenames aren't
> going to bother anyone, I don't think. Not so sure about your new
> proposed design's space usage.
I guess that's a call the community
Vaibhav Kaushal wrote:
> On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
> > On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> > > An quicksort method in
> > > sequential disk its just awful to be thinking in a non SSD world, but
> > > its possible in an SSD.
> >
> > So, code it. Shouldn't be
Tom Lane wrote:
> Jeff Janes writes:
> > Of course if you do a full table scan because their are no better
> > options, then it scans sequentially. But you have to scan the pages
> > in *some* order, and it is hard to see how something other than
> > sequential would be systematically better.
>
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
>> In practice I think it would make sense if heap_open accepts all
>> relation types on which you can potentially do either a heapscan or
>> indexscan (offhand those should be the same set of relkinds, I
On Dec 29, 2010, at 12:00 PM, Bruce Momjian wrote:
> Don't people normally define the version number in the Makefile and pass
> the version string into the C code and perhaps a psql variable?
There is no standard pattern AFAIK. A best practice would be welcome here.
David
--
Sent via pgsql-hac
Excerpts from Kevin Grittner's message of mié dic 29 12:20:20 -0300 2010:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/slru.h;h=710cca70acd67e03e5f3a255b048a719ae4c4709
>
> The way I read this, each segment is (BLCKSZ *
> SLRU_PAGES_PER_SEGMENT) long, which is
Oleg Bartunov wrote:
> Hi there,
>
> it's clear we need versions, probably, major.minor would be enough. The
> problem
> I see is how to keep .so in sync with .sql ? Should we store .sql in database
> ?
>
> Also, we need permissions for extension, since we have open/closed
> extensions.
>
Do
Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
> In practice I think it would make sense if heap_open accepts all
> relation types on which you can potentially do either a heapscan or
> indexscan (offhand those should be the same set of relkinds, I think;
> so this is the same
Robert Haas writes:
> The existing comments mention that callers must check that the return
> value is not a view, if they care. So if there is currently a single
> coherent definition for what heap_open is supposed to do, it's clearly
> NOT the one Heikki proposes. My guess is that reality is c
On Tue, Dec 28, 2010 at 11:07:59PM +, Peter Geoghegan wrote:
> On 28 December 2010 20:07, Peter Eisentraut wrote:
> > The phrase "common table expression" does not appear anywhere in the SQL
> > standard. The standard uses the grammar symbol .
>
> I think we're losing sight of the issue a bi
On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas wrote:
> On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
> > Is it really stable enough for bin/? My impression of the state of
> > affairs is that there is nothing whatsoever about replication that
> > is really stable yet.
>
> Well, that's not stoppin
Excerpts from Magnus Hagander's message of mié dic 29 11:40:34 -0300 2010:
> On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
> > Any specific reason NOREPLICATION_P and REPLICATION_P use the _P suffix?
>
> Um, I just copied it off a similar entry elsewhere. I saw no comment
> about what _P a
Robert Haas writes:
> On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
>> I really really dislike the notion of a "verification scan": it's
>> basically work that is going to be useless if it fails.
> I think it has potential in cases like text to xml. In that case it'll
> either work or fail, wi
On Dec 29, 2010, at 10:14 AM, Magnus Hagander wrote:
> We can be held responsible for the packaging decisions if they use
> *our* "make install" commands, imho.
Yep.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
> I really really dislike the notion of a "verification scan": it's
> basically work that is going to be useless if it fails.
I think it has potential in cases like text to xml. In that case it'll either
work or fail, with no possibility of requirin
"Kevin Grittner" wrote:
>> Any chance of upgrading the lock to a relation lock, or killing
>> the serializable transaction instead?
>
> Absolutely. Good suggestion. Thanks!
I pushed a TODO SSI comment at the appropriate point with my ideas
on how best to fix this. I want to stick with the
Bruce Momjian wrote:
> Yes, that was my calculus too. I realized that we create session ids by
> merging the process id and backend start time, so I went ahead and added
> the postmaster start time epoch to the postmaster.pid file. While there
> is no way to pass back the postmaster start time fr
On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
> Is it really stable enough for bin/? My impression of the state of
> affairs is that there is nothing whatsoever about replication that
> is really stable yet.
Well, that's not stopping us from shipping a core feature called "replication".
I'll de
On Dec 29, 2010, at 12:49 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, I believe the idea of heap_open is to check that the relation is
>> backed by a heap that you can read with heap_beginscan+heap_next. At the
>> moment that includes normal tables, sequences and toast tables. Fore
Heikki Linnakangas wrote:
> Looking at the predicate lock splitting, it occurs to me that
> it's possible for a non-serializable transaction to be canceled if
> it needs to split a predicate lock held by a concurrent
> serializable transaction, and you run out of space in the shared
> memory pre
David Fetter writes:
> On Wed, Dec 29, 2010 at 11:47:53AM +0100, Magnus Hagander wrote:
>> Would people be interested in putting pg_streamrecv
>> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
>> 9.1? I think it would make sense to do so.
> +1 for bin/
Is it really stable en
On 26.12.2010 21:40, Kevin Grittner wrote:
To recap, I've had an open question on the Serializable Wiki page[1]
since January about how we should handle long-running transactions.
The algorithm published by Cahill et al requires keeping some
transaction information in memory for all committed tra
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> > some
> > cases, we can determine that doing so is unhelpful, and that the conversion
> > shall always succeed:
> > I wish to replace ta
On Wed, Dec 29, 2010 at 11:47:53AM +0100, Magnus Hagander wrote:
> Would people be interested in putting pg_streamrecv
> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
> 9.1? I think it would make sense to do so.
+1 for bin/
Cheers,
David.
--
David Fetter http://fetter.org/
Heikki Linnakangas writes:
> Hmm, I believe the idea of heap_open is to check that the relation is
> backed by a heap that you can read with heap_beginscan+heap_next. At the
> moment that includes normal tables, sequences and toast tables. Foreign
> tables would not fall into that category.
I
On 29.12.2010 13:17, Robert Haas wrote:
Did you read the whole thread?
Ah, sorry:
I've had to change some of the heap_open(rv) calls to
relation_open(rv) to avoid having the former throw the wrong error
message before the latter kicks in. I think there might be stylistic
objections to that,
Robert Haas writes:
> On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
>> The exemptor shall have this signature:
>>
>> exemptor_func(
>> integer, -- source_typmod
>> integer -- dest_typmod
>> ) RETURNS boolean
>>
>> The exemptor shall return true iff datumIsEqual(x,
>> x::target_type(dest_typm
- Original Message -
From: "Tom Lane"
To: "Robert Haas"
Cc: "Simon Riggs" ; "Jie Li" ;
"pgsql-hackers"
Sent: Wednesday, December 29, 2010 10:59 PM
Subject: Re: [HACKERS] small table left outer join big table
> Robert Haas writes:
>> On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wr
Thank you for all your comments.
I think the condition of this optimization is whether the small table can fit
into memory. If not, then it doesn't work since two tables still need to be
written to disk. But if yes, we can save all I/O costs in the hash join
process.
Thanks,
Li Jie
- Ori
- Original Message -
From: "Alvaro Herrera"
To: "Robert Haas"
Cc: "Jie Li" ; "pgsql-hackers"
Sent: Wednesday, December 29, 2010 8:39 PM
Subject: Re: [HACKERS] small table left outer join big table
> Excerpts from Robert Haas's message of mié dic 29 09:17:17 -0300 2010:
>> On Tue, Dec
Noah Misch writes:
> ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> some
> cases, we can determine that doing so is unhelpful, and that the conversion
> shall always succeed:
> I wish to replace table rewrites with table verification scans where possible,
> then skip
On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
> ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> some
> cases, we can determine that doing so is unhelpful, and that the conversion
> shall always succeed:
>
> CREATE DOMAIN loosedom AS text;
> CREATE TABLE t (c varchar
2010/12/29 Tom Lane
> I think they're fundamentally different things, because the previously
> proposed patch is an extension of the machine-readable archive format,
> and has to remain so because of the expectation that people will want
> to use parallel restore with it. Joel is arguing for a s
Heikki Linnakangas wrote:
> I'm not sure how you arrived at that number, though.
http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/slru.h;h=710cca70acd67e03e5f3a255b048a719ae4c4709
The way I read this, each segment is (BLCKSZ *
SLRU_PAGES_PER_SEGMENT) long, which
On Wed, Dec 29, 2010 at 16:12, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Dec 28, 2010 at 16:15, Tom Lane wrote:
>>> Also, if you really do need to figure out which PG headers you're
>>> compiling against, looking at catversion.h is the accepted way to do it.
>>> There's no need for ye
Tom Lane wrote:
> I've been fooling around with creating upgrade-in-place support for the
> Fedora/RHEL RPMs. What I want to have is a separate postgresql-upgrade
> RPM containing just the minimum possible set of previous-release files,
> together with pg_upgrade itself. Experimenting with this c
Magnus Hagander writes:
> On Tue, Dec 28, 2010 at 16:15, Tom Lane wrote:
>> Also, if you really do need to figure out which PG headers you're
>> compiling against, looking at catversion.h is the accepted way to do it.
>> There's no need for yet another symbol.
> This file is, AFAIK, not included
Aidan Van Dyk writes:
> On Wed, Dec 29, 2010 at 9:11 AM, Gurjeet Singh
> wrote:
>> AFAIK, that applies to parallel dumps of data (may help in --schema-only
>> dumps too), and what you are trying is for schema.
> Right, but one of the things it does is break the dump in to parts,
> and put them
Robert Haas writes:
> On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
>> It's not a bug, that's the way it currently works. We don't need a test
>> case for that.
> Oh, you're right. I missed the fact that it's a left join.
The only thing that struck me as curious about it was that the OP
On Tue, Dec 28, 2010 at 16:15, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Dec 28, 2010 at 13:18, Robert Haas wrote:
>>> Adding a #define to our headers that you can test for seems like the way to
>>> go.
>
>> That's kind of what I was going for ;)
>
> I don't see the point. You're go
On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
> On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander
> wrote:
>>
>> > Ok, here's an updated patch that does both these and includes
>> > documentation and regression test changes. With that, I think we're
>> > good to go.
>>
>> I've applied this v
On Wed, Dec 29, 2010 at 9:11 AM, Gurjeet Singh wrote:
> On Wed, Dec 29, 2010 at 8:31 AM, Joel Jacobson wrote:
>>
>>
>> 2010/12/29 Aidan Van Dyk
>>>
>>> On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson
>>> wrote:
>>>
>>>
>>>
>>> So, how different (or not) is this to the "directory" format that wa
On Wed, Dec 29, 2010 at 8:31 AM, Joel Jacobson wrote:
>
>
> 2010/12/29 Aidan Van Dyk
>
> On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson
>> wrote:
>>
>>
>>
>> So, how different (or not) is this to the "directory" format that was
>> coming out of the desire of a parallel pg_dump?
>>
>
> Not sure
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander wrote:
> > Ok, here's an updated patch that does both these and includes
> > documentation and regression test changes. With that, I think we're
> > good to go.
>
> I've applied this version (with some minor typo-fixes).
>
>
Do you think we could ha
2010/12/29 Aidan Van Dyk
> On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson
> wrote:
>
>
>
> So, how different (or not) is this to the "directory" format that was
> coming out of the desire of a parallel pg_dump?
>
Not sure what format you are referring to? Custom, tar or plain text?
I noticed t
On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson wrote:
So, how different (or not) is this to the "directory" format that was
coming out of the desire of a parallel pg_dump?
a.
--
Aidan Van Dyk Create like a god,
ai...@highrise.ca
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
> On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
>> >
>> > Here I have a puzzle, why not choose the small table to build hash table?
>> > It
>> > can avoid multiple batches thus save significant I/O cost, isn't it?
>>
>> Yeah, you'd think
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
CREATE DOMAIN loosedom AS text;
CREATE TABLE t (c varchar(2));
ALTER TABLE t ALTER c TYPE varchar(4);
ALTER TABLE t ALTE
On 2010-12-29 2:14 PM, Greg Smith wrote:
MERGE INTO Stock t
USING (VALUES(10,100)) AS s(item_id,balance)
ON s.item_id=t.item_id
WHEN MATCHED THEN UPDATE SET balance=t.balance + s.balance
WHEN NOT MATCHED THEN INSERT VALUES(s.item_id,s.balance)
;
If you can suggest an alternate way to e
Excerpts from Robert Haas's message of mié dic 29 09:17:17 -0300 2010:
> On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> > Hi,
> >
> > Please see the following plan:
> >
> > postgres=# explain select * from small_table left outer join big_table using
> > (id);
> >
On Wed, Dec 29, 2010 at 13:03, Euler Taveira de Oliveira
wrote:
> Em 29-12-2010 07:47, Magnus Hagander escreveu:
>>
>> Would people be interested in putting pg_streamrecv
>> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
>> 9.1? I think it would make sense to do so.
>>
> +1 bu
On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
> >
> > Here I have a puzzle, why not choose the small table to build hash table? It
> > can avoid multiple batches thus save significant I/O cost, isn't it?
>
> Yeah, you'd think. Can you post a full reproducible test case?
It's not a bug, t
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> Hi,
>
> Please see the following plan:
>
> postgres=# explain select * from small_table left outer join big_table using
> (id);
> QUERY PLAN
> -
On Mon, Dec 27, 2010 at 3:58 AM, Simon Riggs wrote:
> I think the answer is that only the first column comparison is
> optimised. Second and subsequent comparisons are not optimised.
What sort of optimization are you referring to here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Th
I did some basic testing of the latest update here, but quickly hit a
problem that wasn't in the previous version. Attached is the standalone
test script that used to work, but now fails like this:
psql:simple.sql:12: ERROR: the vars in merge action tlist of qual
should only belongs to the s
Em 29-12-2010 07:47, Magnus Hagander escreveu:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
+1 but...
It could/should then also become the default tool for doing
base-backup-o
Erik Rijkers wrote:
I get some whitespace-warnings, followed by error:
$ git apply
/home/rijkers/download/pgpatches/0091/merge/20101206/merge_204_2010DEC06.patch
/home/rijkers/download/pgpatches/0091/merge/20101206/merge_204_2010DEC06.patch:481:
trailing
whitespace.
/home/rijkers/download/pg
On Wed, Dec 29, 2010 at 4:19 AM, Yeb Havinga wrote:
> Also, the terms CTE and CTEScan appear in EXPLAIN output, it would be nice
> to have a meaningful hit when looking for the term in the documentation
> page, instead of 'Your search for cte returned no hits.'
This is an excellent point.
--
Ro
On Wed, Dec 29, 2010 at 5:47 AM, Magnus Hagander wrote:
> Would people be interested in putting pg_streamrecv
> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
> 9.1? I think it would make sense to do so.
>
> It could/should then also become the default tool for doing
> base-ba
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
wrote:
> On 29.12.2010 06:54, Robert Haas wrote:
>>
>> With the patch:
>>
>> rhaas=# cluster v;
>> ERROR: views do not support CLUSTER
>
> "do not support" sounds like a missing feature, rather than a nonsensical
> command. How about something
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
It could/should then also become the default tool for doing
base-backup-over-libpq, assuming me or Heikki (or somebody else)
finishes o
1 - 100 of 107 matches
Mail list logo
