On tor, 2012-04-12 at 11:59 +0200, Magnus Hagander wrote:
> The SELECT manpage has:
>
> and with_query is:
>
> with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
> update | delete )
>
>
> Should that list that you can use values as well? Or is it something
> we generally con
On Fri, Apr 13, 2012 at 10:43 PM, Pavel Stehule wrote:
>> Yeah. I think it would be a good idea for UPDATE and DELETE to expose
>> a LIMIT option, but I can't really see the virtue in making that
>> functionality available only through SPI.
>
> I don't agree - LIMIT after UPDATE or DELETE has no
On Fri, Apr 13, 2012 at 10:01 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Apr 13, 2012 at 8:15 PM, Robert Haas wrote:
>>> That's probably true, but I'm not sure it's worth worrying about -
>>> one-in-four-billion is a pretty small probability.
>
>> Is this not subject to the birthday par
On 14 April 2012 03:01, Tom Lane wrote:
> Realistically, I'm more worried about collisions due to inadequacies in
> the jumble calculation logic (Peter already pointed out some risk
> factors in that regard).
It's important to have a sense of proportion about the problem. The
worst thing that a c
>
> Yeah. I think it would be a good idea for UPDATE and DELETE to expose
> a LIMIT option, but I can't really see the virtue in making that
> functionality available only through SPI.
>
I don't agree - LIMIT after UPDATE or DELETE has no sense. Clean
solution should be based on using updateable
Greg Stark writes:
> On Fri, Apr 13, 2012 at 8:15 PM, Robert Haas wrote:
>> That's probably true, but I'm not sure it's worth worrying about -
>> one-in-four-billion is a pretty small probability.
> Is this not subject to the birthday paradox? If you have a given hash
> you're worried about a co
On Fri, Apr 13, 2012 at 8:15 PM, Robert Haas wrote:
> That's probably true, but I'm not sure it's worth worrying about -
> one-in-four-billion is a pretty small probability.
Is this not subject to the birthday paradox? If you have a given hash
you're worried about a collision with then you have a
Ozgun Erdogan writes:
> (1) What's the difference between advancing the command counter and
> updating an active snapshot? For example, I see that DefineRelation()
> increments the command counter, but explain.c / copy.c explicitly
> calls UpdateActiveSnapshotCommandId(). Is that because the latte
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote:
> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote:
>> umi.tan...@gmail.com writes:
>>> http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
>>
>>> ===
>>> SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
>>> will allow at m
Jim Nasby writes:
> I agree that ms is on it's way out... and frankly it wouldn't surprise me if
> at some point we actually had need of ns resolution.
> Given that, I don't think ms or us definitions make sense... float8 seconds
> seams much more logical to me.
Well, the important point is th
On fre, 2012-04-13 at 17:27 +0900, Etsuro Fujita wrote:
> This is a little patch to fix a typo in file-fdw.sgml
Fixed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On tis, 2012-04-10 at 09:33 -0400, Robert Haas wrote:
> So, should we make the new columns exposed by pg_stat_statements use
> milliseconds, so that the block read/write timings are everywhere in
> milliseconds, or should we keep them as a float8, so that all the
> times exposed by pg_stat_statemen
On tor, 2012-04-12 at 18:19 -0400, Christopher Browne wrote:
> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt wrote:
> > Rather than extend the CF app into a trivial-patch workflow app, it might be
> > worth looking at integrating it with github.
>
> There's a reluctance to require a proprietary com
On tor, 2012-04-12 at 07:59 +0200, Magnus Hagander wrote:
> It might be helpful (if the CF app had a trivial API) with a small
> tool that could run from a git hook (or manual script or alias) that
> would prompt for "which cf entry, if any, did this commit close"?
An API for the CF app would actu
On ons, 2012-04-11 at 23:30 -0400, Robert Haas wrote:
> Now what would be sort of neat is if we had a way to keep all the
> versions of patch X plus author and reviewer information, links to
> reviews and discussion, etc. in some sort of centralized place.
Well, a properly linked email thread cont
On 4/10/12 5:07 PM, Greg Smith wrote:
I'd prefer to see at least usec resolution and 8 bytes of "dynamic range" for
query related statistics. Any of these would be fine from a UI perspective to me:
-float8 seconds
-float8 msec
-float8 usec
-int8 usec
I don't think int8 msec will be enough res
On 13 April 2012 20:15, Robert Haas wrote:
> On Wed, Apr 11, 2012 at 9:02 AM, k...@rice.edu wrote:
>> By using all 64-bits of the hash that we currently calculate, instead
>> of the current use of 32-bits only, the collision probabilities are
>> very low.
>
> That's probably true, but I'm not sur
On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao wrote:
>>> I can see a usecase for having a pg_size_pretty(numeric) as an option.
>>> Not necessarily a very big one, but a >0 one.
>>
>> +1.
>
> +1, too.
I did some beautification of this patch. I think the attached version
is cleaner and easier to
On Fri, Apr 13, 2012 at 4:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On another note, I think this is a sufficiently major change that we
>> ought to add Peter's name to the "Author" section of the
>> pg_stat_statements documentation.
>
> +1 ... as long as we have those at all, they probably
Robert Haas writes:
> On another note, I think this is a sufficiently major change that we
> ought to add Peter's name to the "Author" section of the
> pg_stat_statements documentation.
+1 ... as long as we have those at all, they probably ought to credit
anybody who did substantial work on the m
On 04/13/2012 08:15 PM, Kevin Grittner wrote:
Robert Haas wrote:
In my view, remote_write seems a lot more clear than write
+1
I sure didn't understand it to mean remote_write when I read the
subject line.
Neither did I. So definitely +1.
--
Guillaume
http://www.postgresql.fr
http://
On 13.04.2012 22:02, Tom Lane wrote:
Heikki Linnakangas writes:
On 13.04.2012 21:43, Peter Eisentraut wrote:
The commands PREPARE TRANSACTION, COMMIT PREPARED, and ROLLBACK PREPARED
are the only ones that do not have a Compatibility section on their
reference page. Does anyone remember whethe
On 13 April 2012 19:15, Kevin Grittner wrote:
> Robert Haas wrote:
>
>> In my view, remote_write seems a lot more clear than write
>
> +1
>
> I sure didn't understand it to mean remote_write when I read the
> subject line.
Whatever this option value is named, it needs to be referenced in the
pos
On Wed, Apr 11, 2012 at 9:02 AM, k...@rice.edu wrote:
> By using all 64-bits of the hash that we currently calculate, instead
> of the current use of 32-bits only, the collision probabilities are
> very low.
That's probably true, but I'm not sure it's worth worrying about -
one-in-four-billion is
Heikki Linnakangas writes:
> On 13.04.2012 21:43, Peter Eisentraut wrote:
>> The commands PREPARE TRANSACTION, COMMIT PREPARED, and ROLLBACK PREPARED
>> are the only ones that do not have a Compatibility section on their
>> reference page. Does anyone remember whether they were our invention or
>
On 13.04.2012 21:43, Peter Eisentraut wrote:
The commands PREPARE TRANSACTION, COMMIT PREPARED, and ROLLBACK PREPARED
are the only ones that do not have a Compatibility section on their
reference page. Does anyone remember whether they were our invention or
copied from or inspired by some other
The commands PREPARE TRANSACTION, COMMIT PREPARED, and ROLLBACK PREPARED
are the only ones that do not have a Compatibility section on their
reference page. Does anyone remember whether they were our invention or
copied from or inspired by some other implementation?
--
Sent via pgsql-hackers m
Robert Haas wrote:
> In my view, remote_write seems a lot more clear than write
+1
I sure didn't understand it to mean remote_write when I read the
subject line.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On 13 April 2012 18:33, Robert Haas wrote:
> We do use insertion sort for partitions of size < 7. I assume you are
> referring to something else.
I stand corrected. My confusion came from the removal of a later
*switch* to insertion sort in
a3f0b3d68f9a5357a3f72b40a45bcc714a9e0649, which also ad
Alvaro Herrera writes:
> Excerpts from Andrew Dunstan's message of mié abr 11 15:51:51 -0300 2012:
>> On 04/11/2012 02:45 PM, Tom Lane wrote:
>>> I don't really care for the idea that the ONLY goes in a different place
>>> for this operation than for every other kind of ALTER TABLE, but it does
>
Hi all (re-posting from pgsql-general),
I'm looking into Postgres' internals, and had two quick questions that
relate to each other.
(1) What's the difference between advancing the command counter and
updating an active snapshot? For example, I see that DefineRelation()
increments the command cou
On Fri, Apr 13, 2012 at 1:15 PM, Peter Geoghegan wrote:
> On 13 April 2012 17:42, Peter Geoghegan wrote:
>> One insight that I had at the time was that text comparisons where the
>> c locale isn't used are really rather expensive, and I doubt that
>> there is too much that can be done to address
On Fri, Apr 13, 2012 at 12:40:09PM -0400, Robert Haas wrote:
> On Fri, Apr 13, 2012 at 11:23 AM, Bruce Momjian wrote:
> > I just talked to Tom about the 9.2 release notes. Do people want me to
> > write the 9.2 release notes?
>
> +1.
>
> > When do you think we will be ready for 9.2
> > beta?
>
On 13 April 2012 17:42, Peter Geoghegan wrote:
> One insight that I had at the time was that text comparisons where the
> c locale isn't used are really rather expensive, and I doubt that
> there is too much that can be done to address that directly. However,
> if we were to support timsort, that
On Thu, Jan 26, 2012 at 1:21 AM, Fujii Masao wrote:
> On Wed, Jan 25, 2012 at 11:12 PM, Simon Riggs wrote:
>> On Wed, Jan 25, 2012 at 1:57 PM, Robert Haas wrote:
>>
>>> I think that this would be a lot more clear if we described this as
>>> synchronous_commit = remote_write rather than just sync
On Fri, Apr 13, 2012 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 13, 2012 at 11:23 AM, Bruce Momjian wrote:
>>> When do you think we will be ready for 9.2
>>> beta?
>
>> Well, we've got a bunch of open issues, but most of them don't look
>> *too* serious. If everyone dropp
Robert Haas writes:
> On Fri, Apr 13, 2012 at 11:23 AM, Bruce Momjian wrote:
>> When do you think we will be ready for 9.2
>> beta?
> Well, we've got a bunch of open issues, but most of them don't look
> *too* serious. If everyone dropped what they're doing and worked on
> them, I think we coul
On Fri, Apr 13, 2012 at 8:12 AM, Christoph Berg wrote:
> diff --git a/doc/src/sgml/high-availability.sgml
> b/doc/src/sgml/high-availability.sgml
Thanks for the patch; however, please attach patches rather than
including them inlined; they don't extract cleanly when included
inline, at least not
On 13 April 2012 16:03, Greg Stark wrote:
> Fwiw it also only holds for comparison sorts. If you can sort your
> items without actually comparing each item with the others then you
> aren't bound by it at all. Notably algorithms like radix sort and
> direct sort aren't bound by it and are O(n). I'
On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane wrote:
>>> After some reflection I think that the blame should be pinned on
>>> have_relevant_joinclause(), which is essentially defined as "is there
>>> any join clause that can
On Fri, Apr 13, 2012 at 11:23 AM, Bruce Momjian wrote:
> I just talked to Tom about the 9.2 release notes. Do people want me to
> write the 9.2 release notes?
+1.
> When do you think we will be ready for 9.2
> beta?
Well, we've got a bunch of open issues, but most of them don't look
*too* seri
Currently, we have a problem with index-only scans in Hot Standby
mode: the xmin horizon on the standby might lag the master, and thus
an index-only scan might mistakenly conclude that no heap fetch is
needed when in fact it is. I suggested that we handle this by
suppressing generation of index-on
On Thu, 2012-04-12 at 12:28 +0300, Heikki Linnakangas wrote:
> On 08.04.2012 11:59, Guillaume Lelarge wrote:
> > Hi,
> >
> > I recently wrote a plpgsql plugin. I wanted to enable the use of pgxs,
> > to make it easier to compile the plugin, but I eventually found that I
> > can't do that because th
I just talked to Tom about the 9.2 release notes. Do people want me to
write the 9.2 release notes? When do you think we will be ready for 9.2
beta?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everythi
On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas wrote:
> On Sun, Mar 18, 2012 at 11:25 AM, Tom Lane wrote:
>> So has somebody found a hole in the n log n lower bound on the cost of
>> comparison-based sorting? I thought that had been proven pretty
>> rigorously.
>
> There's not much danger of anyon
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm a bit worried, though, that with all the planner changes this
> release we are going to spend a lot of time tracking down regressions
> either in planning time or in plan quality.
I dunno, I agree that there will likely be more regression
Robert Haas writes:
> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane wrote:
>> After some reflection I think that the blame should be pinned on
>> have_relevant_joinclause(), which is essentially defined as "is there
>> any join clause that can be evaluated at the join of these two
>> relations?". I
On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane wrote:
> I looked into the behavior complained of here:
> http://archives.postgresql.org/pgsql-performance/2012-04/msg00093.php
>
> The problem query can be abstracted to
>
> select * from a, b, c, d
> where a.x = b.y and (a.z = c.c or a.z =
On Wed, Mar 21, 2012 at 8:57 PM, Jeff Janes wrote:
> On Mon, Mar 19, 2012 at 12:23 PM, Robert Haas wrote:
> ...
>>
>> One thing that seems inefficient to me about our current algorithm is
>> the use of the run number as a leading column in the sort key.
>> There's no real reason why the tuples de
I looked into the behavior complained of here:
http://archives.postgresql.org/pgsql-performance/2012-04/msg00093.php
The problem query can be abstracted to
select * from a, b, c, d
where a.x = b.y and (a.z = c.c or a.z = d.d)
Table a is much larger than the others (in fact, in th
On Thu, Apr 12, 2012 at 3:27 PM, Tom Lane wrote:
> 1. Lobotomize add_path_precheck so it always returns true for a
> parameterized path. This sounds horrid, but in the test cases I'm using
> it seems that this only results in doing the full path construction for
> a very small number of additiona
Jeff Davis writes:
> On Sun, 2012-03-18 at 11:25 -0400, Tom Lane wrote:
>> Yeah, that was me, and it came out of actual user complaints ten or more
>> years back. (It's actually not 2X growth but more like 4X growth
>> according to the comments in logtape.c, though I no longer remember the
>> exa
On tor, 2012-04-12 at 10:12 -0500, Joshua Berkus wrote:
> Well actually, the other advantage of using branches is that it would
> encourage committers to bounce a patch back to the submitter for
> modification *instead of* doing it themselves. This would both have
> the advantage of saving time fo
On 04/13/2012 07:21 AM, Shigeru HANADA wrote:
> (2012/04/13 16:59), Etsuro Fujita wrote:
>> I updated the patch added to CF 2012-Next [1]. Attached is the updated
>> version of the patch.
> I applied the patch and ran regression tests of file_fdw, and I got
> SIGSEGV X-(
>
> The failure occurs i
diff --git a/doc/src/sgml/high-availability.sgml
b/doc/src/sgml/high-availability.sgml
new file mode 100644
index ed34dac..c5f3ff9
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*** primary_conninfo = 'host=192.168.1.50 po
*** 1022,1028
(2012/04/13 16:59), Etsuro Fujita wrote:
> I updated the patch added to CF 2012-Next [1]. Attached is the updated
> version of the patch.
I applied the patch and ran regression tests of file_fdw, and I got
SIGSEGV X-(
The failure occurs in fileGetOptions, and it is caused by
list_delete_cell use
Robert Haas writes:
> The real problem with the command triggers patch is that we got a
> blizzard of code. It's unrealistic to expect anyone to devote serious
> review time to a patch that's under constant development. It also
> strikes me that a tremendous amount of pain could have been avoide
Tom Lane writes:
> Andres Freund writes:
>> They might have been half-baked. But several of those didn't get design-level
>> review for several weeks which makes it rather hard to fully bake them in
>> time...
>
> But if they didn't already have design-level review, that means they
> were not se
Robert Haas writes:
> Even before this CommitFest, it's felt to me like this hasn't been a
> great cycle for reviewing. I think we have generally had fewer people
> doing reviews than we did during the 9.0 and 9.1 cycles. I think we
> had a lot of momentum with the CommitFest process when it was
This is a little patch to fix a typo in file-fdw.sgml
Best regards,
Etsuro Fujita
file_fdw_typo_fix_20120413.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
I updated the patch added to CF 2012-Next [1]. Attached is the updated
version of the patch.
For the discussion in [2], I've introduced a new generic option, validate
for file_fdw foreign tables, which specifies if file_fdw verifies that
tuples meet NOT NULL constraints. The default value for th
61 matches
Mail list logo
