Hackers, users, pgCon attendees:
You want to give a lightning talk at pgCon!
Yes, you do. The fun, the glory, the laughter, the everlasting fame!
These can all be yours.
Be one of the ten "brave and true" who put together five minutes about
PostgreSQL tools, experiences, forks, ideas, websites,
> Those are the basic requirements that I am trying to address. There
> are a great many important details, but the core of this is probably
> what I would call "logical replication", that is shipping changes to
> other nodes in a way that does not tie us to the same physical
> representation that
>> Well, this *is* the purpose of the cluster-hackers group
>
> Well, I tried all available means to discuss my ideas before
> organising an external meeting. You can think of the InCore meeting as
> an extension of the cluster hackers meeting if you wish.
That comment wasn't for you, it was for
On Mon, Apr 30, 2012 at 11:43 PM, Josh Berkus wrote:
> Well, this *is* the purpose of the cluster-hackers group
Well, I tried all available means to discuss my ideas before
organising an external meeting. You can think of the InCore meeting as
an extension of the cluster hackers meeting if you w
>> If we just had that much in core - that is, the ability to efficiently
>> extra tuple inserts, updates, and deletes on a logical level - it
>> would be much easier to build a good logical replication system around
>> PostgreSQL than it is today, and the existing systems could be adapted
>> to d
Robert Haas wrote:
> Hopefully that's not too hard to fix; the basic approach seems
> quite promising.
After playing with trigram searches for name searches against copies
of production database with appropriate indexing, our shop has
chosen it as the new way to do name searches here. It's re
On Mon, Apr 30, 2012 at 2:38 PM, Robert Haas wrote:
> On Mon, Apr 30, 2012 at 2:33 PM, Merlin Moncure wrote:
>> On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
>>> For example, you said that "MM replication alone is not a solution for
>>> large data or the general case". Why is that? Is
Robert Haas wrote:
> The other half of the changes - applying the updates - is
> relatively straightforward, and it wouldn't bother me to leave
> that in user-land, especially in the MMR case, where you have to
> deal with conflict resolution rules that may be much simpler to
> express in a high
On Mon, Apr 30, 2012 at 07:55:00PM +0100, Simon Riggs wrote:
> On Mon, Apr 30, 2012 at 6:38 PM, Bruce Momjian wrote:
>
> > I would love to see a layout of exactly where these things make sense,
> > similar to what we do at the bottom of our documentation for "High
> > Availability, Load Balancing
"David Johnston" wrote:
>> I think you could test for integer-ness by testing whether val % 0 =
0.
> Modulus is a division function anything "% 0" results in a
division-by-zero
It seems pretty clear that he meant "% 1".
test=# select '1.01'::numeric % 1;
?column?
--
0.01
(1
On Mon, Apr 30, 2012 at 3:33 PM, David Johnston wrote:
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>> ow...@postgresql.org] On Behalf Of Robert Haas
>> Sent: Monday, April 30, 2012 2:20 PM
>> To: Peter Eisentraut
>> Cc: pgsql-hackers
>> Subject:
On Mon, Apr 30, 2012 at 2:33 PM, Merlin Moncure wrote:
> On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
>> For example, you said that "MM replication alone is not a solution for
>> large data or the general case". Why is that? Is the goal of your work
>> really to do logical replciation
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Monday, April 30, 2012 2:20 PM
> To: Peter Eisentraut
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] precision and scale functions for numeric
>
>
Noah Misch wrote:
>> During ANALYZE, in analyze.c, functions compute_minimal_stats
>> and compute_scalar_stats, values whose length exceed
>> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
>> other than that they are counted as "too wide rows" and assumed
>> to be all different.
>
On Mon, Apr 30, 2012 at 6:38 PM, Bruce Momjian wrote:
> I would love to see a layout of exactly where these things make sense,
> similar to what we do at the bottom of our documentation for "High
> Availability, Load Balancing, and Replication":
>
>
> http://www.postgresql.org/docs/9.1/st
Tom Lane wrote:
>>> I'm fairly skeptical that this is a real problem, and would prefer not
>>> to complicate wrappers until we see some evidence from the field that
>>> it's worth worrying about.
>> If I have a table with 10 rows and default_statistics_target
>> at 100, then a sample of 3
Simon Riggs wrote:
>>> During ANALYZE, in analyze.c, functions compute_minimal_stats
>>> and compute_scalar_stats, values whose length exceed
>>> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
>>> other than that they are counted as "too wide rows" and assumed
>>> to be all differ
Noah Misch writes:
> When GIN changes a metapage, we WAL-log its ex-header content and never use a
> backup block. This reduces WAL volume since the vast majority of the metapage
> is unused. However, ginRedoUpdateMetapage() only restores the WAL-logged
> content if the metapage LSN predates the
On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
> For example, you said that "MM replication alone is not a solution for
> large data or the general case". Why is that? Is the goal of your work
> really to do logical replciation, which allows for major version
> upgrades? Is that the def
On Sun, Apr 29, 2012 at 1:51 PM, Peter Eisentraut wrote:
> I didn't find a good way to find out how many digits a numeric value has
> or things like whether a numeric value is an integer. (I had to go
> through bc(1) for the latter.) Functions like precision() and scale()
> would have been quite
On Sun, Apr 29, 2012 at 8:12 AM, Erik Rijkers wrote:
> Perhaps I'm too early with these tests, but FWIW I reran my earlier test
> program against three
> instances. (the patches compiled fine, and make check was without problem).
These tests results seem to be more about the pg_trgm changes tha
On Thu, Apr 26, 2012 at 01:41:33PM +0100, Simon Riggs wrote:
> Some people have talked about the need for "multi-master replication",
> whereby 2+ databases communicate changes to one another. This topic
> has been discussed in some depth in Computer Science academic papers,
> most notably, "The Da
When GIN changes a metapage, we WAL-log its ex-header content and never use a
backup block. This reduces WAL volume since the vast majority of the metapage
is unused. However, ginRedoUpdateMetapage() only restores the WAL-logged
content if the metapage LSN predates the WAL record LSN. If a metap
On Mon, Apr 30, 2012 at 12:27:45PM +0200, Albe Laurenz wrote:
> During ANALYZE, in analyze.c, functions compute_minimal_stats
> and compute_scalar_stats, values whose length exceed
> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
> other than that they are counted as "too wide row
Within access/transam/xlog.c , the following comment has an obvious error:
* (This should not be called for for synchronous commits.)
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-
On Mon, Apr 30, 2012 at 09:02:33AM -0400, Alvaro Herrera wrote:
>
> Excerpts from Ryan Kelly's message of lun abr 30 07:10:14 -0400 2012:
> > On Sun, Apr 29, 2012 at 10:12:40PM -0400, Alvaro Herrera wrote:
> > >
> > > Excerpts from Ryan Kelly's message of sáb ene 14 16:22:21 -0300 2012:
> > >
>
On Mon, Apr 30, 2012 at 3:24 PM, Tom Lane wrote:
> "Albe Laurenz" writes:
>> During ANALYZE, in analyze.c, functions compute_minimal_stats
>> and compute_scalar_stats, values whose length exceed
>> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
>> other than that they are counte
"Albe Laurenz" writes:
> Tom Lane wrote:
>> I'm fairly skeptical that this is a real problem, and would prefer not
>> to complicate wrappers until we see some evidence from the field that
>> it's worth worrying about.
> If I have a table with 10 rows and default_statistics_target
> at 100, th
Greg Stark writes:
> On Sun, Apr 29, 2012 at 12:26 AM, Robert Haas wrote:
>> As for track_iotiming -> track_io_timing, I'm fine with that as well.
> I'm still grumpy about the idea of a GUC changing the explain analyze
> output. How would people feel about adding an explain option that
> explici
On Sun, Apr 29, 2012 at 12:26 AM, Robert Haas wrote:
> As for track_iotiming -> track_io_timing, I'm fine with that as well.
I'm still grumpy about the idea of a GUC changing the explain analyze
output. How would people feel about adding an explain option that
explicitly requests io timing for th
Tom Lane wrote:
>> During ANALYZE, in analyze.c, functions compute_minimal_stats
>> and compute_scalar_stats, values whose length exceed
>> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
>> other than that they are counted as "too wide rows" and assumed
>> to be all different.
>
On Mon, Apr 30, 2012 at 10:26 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Simon Riggs wrote:
>
>>> * throw a WARNING if serializable is stated in other cases, and
>>> downgrade the request to repeatable read
>>
>> I think this would be reasonable, but it's still my second choice.
>> The ad
Robert Haas wrote:
> Simon Riggs wrote:
>> * throw a WARNING if serializable is stated in other cases, and
>> downgrade the request to repeatable read
>
> I think this would be reasonable, but it's still my second choice.
> The advantage of throwing an ERROR is that someone will presumably
> b
"Albe Laurenz" writes:
> During ANALYZE, in analyze.c, functions compute_minimal_stats
> and compute_scalar_stats, values whose length exceed
> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
> other than that they are counted as "too wide rows" and assumed
> to be all different.
Excerpts from Ryan Kelly's message of lun abr 30 07:10:14 -0400 2012:
> On Sun, Apr 29, 2012 at 10:12:40PM -0400, Alvaro Herrera wrote:
> >
> > Excerpts from Ryan Kelly's message of sáb ene 14 16:22:21 -0300 2012:
> >
> > > I have attached a new patch which handles the connect_timeout option by
On Mon, Apr 30, 2012 at 9:55 AM, Wolfgang Wilhelm
wrote:
> Just for the ones interested in a view on another turf:
>
> In Oracle "shutdown immediate" is the fastest _clean_ shutdown and "shutdown
> abort" is equal to "shutdown immediate" in PG.
> The other modes are called "shutdown normal" and "s
On Mon, Apr 30, 2012 at 12:39 PM, Simon Riggs wrote:
> On Mon, Apr 30, 2012 at 7:35 AM, Dave Page wrote:
>> On Sun, Apr 29, 2012 at 11:20 PM, Alvaro Herrera
>> wrote:
>>>
>>> Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs
On Sun, Apr 29, 2012 at 10:12:40PM -0400, Alvaro Herrera wrote:
>
> Excerpts from Ryan Kelly's message of sáb ene 14 16:22:21 -0300 2012:
>
> > I have attached a new patch which handles the connect_timeout option by
> > adding a PQconnectTimeout(conn) function to access the connect_timeout
> > wh
On Sat, Apr 28, 2012 at 17:41, Andrew Dunstan wrote:
>
> On 04/27/2012 12:44 PM, Magnus Hagander wrote:
Hmm. Forgive me, I pressed the wrong button and looked at current docs
rather than dev docs.
(Easier when they used to look different...)
>>>
>>>
>>> Maybe we shoul
During ANALYZE, in analyze.c, functions compute_minimal_stats
and compute_scalar_stats, values whose length exceed
WIDTH_THRESHOLD (= 1024) are not used for calculating statistics
other than that they are counted as "too wide rows" and assumed
to be all different.
This works fine with regular tabl
Just for the ones interested in a view on another turf:
In Oracle "shutdown immediate" is the fastest _clean_ shutdown and "shutdown
abort" is equal to "shutdown immediate" in PG.
The other modes are called "shutdown normal" and "shutdown transactional".
Wolfgang
On Mon, Apr 30, 2012 at 02:23, Devrim GÜNDÜZ wrote:
> On Sun, 2012-04-29 at 13:23 +0100, Simon Riggs wrote:
>> > (As a side note, RPMs *may not* be ready, because I (and Magnus)
>> will be
>> > at PGDay Turkey on 12th, and will be busy over the whole weekend).
>>
>> Is that a closed meeting? I had
Tom Lane wrote:
>> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
>>> No, I'm not happy with that. Smart shutdown is defined to not
affect
>>> current sessions. I'm fine with having a fourth mode that acts as
you
>>> suggest (and, probably, even with making it the default); but not
with
>>> ta
On Mon, Apr 30, 2012 at 7:35 AM, Dave Page wrote:
> On Sun, Apr 29, 2012 at 11:20 PM, Alvaro Herrera
> wrote:
>>
>> Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
>>> On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs wrote:
>>>
>>> > I will also be organising a small-medium si
44 matches
Mail list logo
