> Date: Thu, 22 Mar 2012 13:17:01 -0400
> Subject: Re: [HACKERS] Gsoc2012 Idea --- Social Network database schema
> From: cbbro...@gmail.com
> To: kevin.gritt...@wicourts.gov
> CC: pgsql-hackers@postgresql.org
>
> On Thu, Mar 22, 2012 at 12:38 PM, Kevin Grittner
> wrote:
> > Tom Lane wrote:
I saw Kyotaro already answered, but I give my view as well.
On Thu, Mar 22, 2012 at 06:07:16PM -0400, Tom Lane wrote:
> AFAICT it breaks async processing entirely, because many changes have been
> made that fail to distinguish "insufficient data available as yet" from
> "hard error". As an exampl
On Sat, Mar 24, 2012 at 01:17, Tom Lane wrote:
> I've applied a slightly-modified version of this after reconciling it
> with the protransform fixes.
Cool, thanks!
> I assume you are going to submit a rebased
> version of the main CacheExpr patch?
Yeah, I'm still working on addressing the comme
Marti Raudsepp writes:
> Per Tom's request, I split out this refactoring from my CacheExpr patch.
> Basically I'm just centralizing the eval_const_expressions_mutator()
> call on function arguments, from multiple different places to a single
> location. Without this, it would be a lot harder to i
Alvaro Herrera writes:
> So you still need an index on (oid), one on (extoid), and one on
> (extfeature).
Yes. And the main use case for the index on (extoid) is listing a given
extension's features, that we want to order by their name, then the set
of indexes I've been defining is now:
Indexes:
Excerpts from Dimitri Fontaine's message of vie mar 23 16:51:57 -0300 2012:
>
> Alvaro Herrera writes:
> >> Yes, for pg_depend, no I don't know how to make that work with pointing
> >> to the extensions directly, because the whole point here is to be able
> >> to depend on a feature rather than
On Fri, Mar 23, 2012 at 11:43:25AM -0700, Joshua D. Drake wrote:
>
> Hello,
>
> It has been brought to my attention a few times over the last year
> that I have been over the top in my presentation of myself and have
> in fact alienated and offended many of the community. To be honest I
> am unaw
JD,
> With that, I would like to apologize directly to this community that has
> provided me with so much, not just professionally but personally.
Thank you for the apology.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Alvaro Herrera writes:
>> Yes, for pg_depend, no I don't know how to make that work with pointing
>> to the extensions directly, because the whole point here is to be able
>> to depend on a feature rather than the whole extension.
>
> Yes, I understand that -- but would it work to have the feature
On Fri, Mar 23, 2012 at 11:11 AM, Alvaro Herrera
wrote:
> Are you going to provide a rebased version?
Yes, working on that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 23, 2012 at 11:38:56AM -0700, David Fetter wrote:
> On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
> > Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
> > > On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
> > > > On Wed, Mar 14, 2012
On Fri, Mar 23, 2012 at 1:51 PM, Greg Stark wrote:
> Well it's not entirely unlikely. If you step back a web application
> looks like a big loop with a switch statement to go to different
> pages. It keeps executing the same loop over and over again and there
> are only a smallish number of web pa
On Fri, Mar 23, 2012 at 1:43 PM, Joshua D. Drake wrote:
>
> Hello,
>
> It has been brought to my attention a few times over the last year that I
> have been over the top in my presentation of myself and have in fact
> alienated and offended many of the community. To be honest I am unaware of
> eve
Robert Haas writes:
> What I think is more common is the repeated submission of queries that
> are *nearly* identical, but with either different parameter bindings
> or different constants. It would be nice to have some kind of cache
> that would allow us to avoid the overhead of parsing and plan
Hello,
It has been brought to my attention a few times over the last year that
I have been over the top in my presentation of myself and have in fact
alienated and offended many of the community. To be honest I am unaware
of everything I have done but I do take the opinion of those who have
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
> > On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
> > > On Wed, Mar 14, 2012 at 10:22 AM, David Fetter wrote:
> > > >> I think that instead of in
Excerpts from Dimitri Fontaine's message of vie mar 23 13:12:22 -0300 2012:
>
> Alvaro Herrera writes:
> > Why do features have OIDs? Is this for pg_depend entries? If so, would
> > it work to have pg_depend entries point to extensions instead?
>
> Yes, for pg_depend, no I don't know how to m
On Fri, Mar 23, 2012 at 12:03 PM, Robert Haas wrote:
> On Fri, Mar 23, 2012 at 12:29 PM, Greg Stark wrote:
>> On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane wrote:
>>> The complication, opportunities for bugs, and general slowdown
>>> associated with that would outweigh any possible gain, in the opin
On Fri, Mar 23, 2012 at 5:03 PM, Robert Haas wrote:
> The other thing that makes me skeptical of this proposal is that I am
> not very sure that executing absolutely identical queries is a very
> common use case for a relational database. I suppose there might be a
> few queries that run over and
On Fri, Mar 23, 2012 at 1:52 AM, Simon Riggs wrote:
> So we have this?
>
> Master pg_controldata - OK txid_current_snapshot() - OK
> Standby pg_controldata - OK txid_current_snapshot() - lower value
>
> Are there just 2 standbys? So all standbys have acted identically?
Yes, I believe this is the
On Sat, Mar 24, 2012 at 1:49 AM, Robert Haas wrote:
> On Fri, Mar 23, 2012 at 12:42 PM, Fujii Masao wrote:
>> On Fri, Mar 23, 2012 at 9:41 PM, Robert Haas wrote:
>>> On Fri, Mar 23, 2012 at 6:13 AM, Fujii Masao wrote:
On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander
wrote:
> Mig
On Fri, Mar 23, 2012 at 12:29 PM, Greg Stark wrote:
> On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane wrote:
>> The complication, opportunities for bugs, and general slowdown
>> associated with that would outweigh any possible gain, in the opinion
>> of most hackers who have thought about this.
>
> I w
Noah Misch writes:
> On Fri, Mar 23, 2012 at 11:31:54AM -0400, Tom Lane wrote:
>> ... I've not looked
>> yet at the existing transform functions, but why would they want to know
>> about the original node at all?
> You suggested[1] passing an Expr instead of an argument list, and your reasons
> s
On Fri, Mar 23, 2012 at 12:42 PM, Fujii Masao wrote:
> On Fri, Mar 23, 2012 at 9:41 PM, Robert Haas wrote:
>> On Fri, Mar 23, 2012 at 6:13 AM, Fujii Masao wrote:
>>> On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander
>>> wrote:
Might it be a good idea to put it on it's own row instead of ch
On Fri, Mar 23, 2012 at 9:41 PM, Robert Haas wrote:
> On Fri, Mar 23, 2012 at 6:13 AM, Fujii Masao wrote:
>> On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander wrote:
>>> Might it be a good idea to put it on it's own row instead of changing
>>> the format of an existing row, in order not to break
On Fri, Mar 23, 2012 at 11:29 AM, Greg Stark wrote:
> On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane wrote:
> > The complication, opportunities for bugs, and general slowdown
> > associated with that would outweigh any possible gain, in the opinion
> > of most hackers who have thought about this.
>
>
On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane wrote:
> The complication, opportunities for bugs, and general slowdown
> associated with that would outweigh any possible gain, in the opinion
> of most hackers who have thought about this.
I wouldn't be quite so pessimistic. I think the problem is that
I wrote:
> However, see my response to Robert: why are we passing the original node
> to the transform function at all? It would be more useful and easier to
> work with to pass the function's fully-processed argument list, I believe.
After a bit of looking around, I realize that the current impl
Alvaro Herrera writes:
> Why do features have OIDs? Is this for pg_depend entries? If so, would
> it work to have pg_depend entries point to extensions instead?
Yes, for pg_depend, no I don't know how to make that work with pointing
to the extensions directly, because the whole point here is to
On Fri, Mar 23, 2012 at 11:31:54AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane wrote:
> >> Why exactly was this thought to be a good idea:
> >>
> >>> * A NULL original expression disables use of transform functions while
> >>> * retaining all other
Billy Earney writes:
> I'm wondering if anyone would be interested in a query cache as a backend
> to postgresql?
I believe this has been suggested and rejected several times before.
Did you look through the pgsql-hackers archives?
> To invalidate cache entries, look at the transactions being co
Excerpts from Dimitri Fontaine's message of vie mar 23 12:26:47 -0300 2012:
>
> Alvaro Herrera writes:
> > Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
> >
> >> =# \d pg_extension_feature
> >> Table "pg_catalog.pg_extension_feature"
> >> Column | Type |
Noah Misch writes:
> On Fri, Mar 23, 2012 at 10:55:52AM -0400, Tom Lane wrote:
>> Why exactly was this thought to be a good idea:
>>
>>> * A NULL original expression disables use of transform functions while
>>> * retaining all other behaviors.
> I did it that way because it looked wrong to pass
On 23 March 2012 15:13, Andrew Dunstan wrote:
> Upper casing SQL keywords is a common style, which is used in lots of our
> code (e.g. regression tests, psql queries, pg_dump). I think the default
> should match what is in effect our house style, and what we have
> historically done.
The code doe
Excerpts from Alexander LAW's message of mar mar 20 16:50:14 -0300 2012:
> Thanks, I've understood your point.
> Please look at the patch. It implements the first way and it makes psql
> work too.
Great, thanks. Hopefully somebody with Windows-compile abilities will
have a look at this.
--
Á
Thom Brown writes:
> The new command triggers work correctly.
Thanks for your continued testing :)
> Having looked at your regression tests, you don't seem to have enough
> "before" triggers in the tests. There's no test for before CREATE
> TABLE, CREATE TABLE AS or SELECT INTO. In my tests I
Robert Haas writes:
> On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane wrote:
>> Why exactly was this thought to be a good idea:
>>
>>> * A NULL original expression disables use of transform functions while
>>> * retaining all other behaviors.
> I assumed that we were merely trying to avoid forcing t
On Fri, Mar 23, 2012 at 10:55:52AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > Add notion of a "transform function" that can simplify function calls.
>
> Why exactly was this thought to be a good idea:
>
> > * A NULL original expression disables use of transform functions while
> > * retain
Greetings!
I've done a brief search of the postgresql mail archives, and I've noticed
a few projects for adding query caches to postgresql, (for example,
Masanori Yamazaki's query cache proposal for GSOC 2011), as well as the
query cache announced at http://www.postgresql.org/about/news/1296/
(pg
Alvaro Herrera writes:
> Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
>
>> =# \d pg_extension_feature
>> Table "pg_catalog.pg_extension_feature"
>> Column | Type | Modifiers
>> +--+---
>>extoid | oid | not null
>>extf
On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane wrote:
> Robert Haas writes:
>> Add notion of a "transform function" that can simplify function calls.
>
> Why exactly was this thought to be a good idea:
>
>> * A NULL original expression disables use of transform functions while
>> * retaining all othe
Peter Geoghegan writes:
> On 22 March 2012 22:05, Andrew Dunstan wrote:
>> Should it be governed by a setting?
> Perhaps, but I find the behaviour that was introduced by Peter's patch
> to be a more preferable default.
FWIW, I like the new behavior better too. I'm not particularly a
fan of all
On 03/23/2012 11:07 AM, Peter Geoghegan wrote:
On 22 March 2012 22:05, Andrew Dunstan wrote:
On 03/22/2012 05:49 PM, Bruce Momjian wrote:
Robert Haas and I are disappointed by this change. I liked the fact
that I could post nice-looking SQL queries without having to use my
capslock key (w
Are you going to provide a rebased version?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On 22 March 2012 22:05, Andrew Dunstan wrote:
>
>
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
>>
>>
>> Robert Haas and I are disappointed by this change. I liked the fact
>> that I could post nice-looking SQL queries without having to use my
>> capslock key (which I use as a second control key
Excerpts from Robert Haas's message of mié mar 21 21:50:24 -0300 2012:
> heap_freeze_tuple() was apparently designed at one point to cope with
> being called with either a shared or exclusive buffer lock. But none
> of the current callers call it with a shared lock; they all call it
> with an exc
Robert Haas writes:
> Add notion of a "transform function" that can simplify function calls.
Why exactly was this thought to be a good idea:
> * A NULL original expression disables use of transform functions while
> * retaining all other behaviors.
AFAICT that buys nothing except to greatly com
On Fri, Mar 23, 2012 at 11:51:16AM -0300, Alvaro Herrera wrote:
>
> Excerpts from Andrew Dunstan's message of jue mar 22 19:05:30 -0300 2012:
> >
> > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > >
> > > Robert Haas and I are disappointed by this change. I liked the
> > > fact that I could po
On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> >Robert Haas and I are disappointed by this change. I liked the
> >fact that I could post nice-looking SQL queries without having to
> >use my capslock key (which I use as a second cont
Excerpts from Andrew Dunstan's message of jue mar 22 19:05:30 -0300 2012:
>
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> >
> > Robert Haas and I are disappointed by this change. I liked the fact
> > that I could post nice-looking SQL queries without having to use my
> > capslock key (which I
Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
> =# \d pg_extension_feature
> Table "pg_catalog.pg_extension_feature"
> Column | Type | Modifiers
> +--+---
>extoid | oid | not null
>extfeature | name | not null
> In
* Robert Haas (robertmh...@gmail.com) wrote:
> Well, how do you want to look at it?
I thought the last graph you provided was a useful way to view the
results. It was my intent to make that clear in my prior email, my
apologies if that didn't come through.
> Here's the data from 80th
> percent
On Thu, Mar 22, 2012 at 12:56 AM, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 5:48 AM, Fujii Masao wrote:
>> Hi,
>>
>> In streaming replication, after failover, new master might have lots
>> of un-applied
>> WAL files with old timeline ID. They are the WAL files which were recycled
>> as a
>> f
On Wed, Mar 21, 2012 at 10:51 PM, Atri Sharma wrote:
> Please let me know how to proceed further.
>
> Waiting for your reply,
sure -- let's take this discussion off line. send me a private mail
and we'll discuss if/how we can get this off the ground.
merlin
--
Sent via pgsql-hackers mailing l
On Fri, Mar 23, 2012 at 6:13 AM, Fujii Masao wrote:
> On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander wrote:
>> Might it be a good idea to put it on it's own row instead of changing
>> the format of an existing row, in order not to break scripts and
>> programs that are parsing the previous outp
On Thu, Mar 22, 2012 at 8:44 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost wrote:
>> > Well, those numbers just aren't that exciting. :/
>>
>> Agreed. There's clearly an effect, but on this test it's not very big.
>
> Ok
On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander wrote:
> Might it be a good idea to put it on it's own row instead of changing
> the format of an existing row, in order not to break scripts and
> programs that are parsing the previous output?
Good idea! What row name should we use for the WAL fi
On Fri, Mar 23, 2012 at 10:51, Fujii Masao wrote:
> On Fri, Mar 23, 2012 at 2:06 PM, Jaime Casanova wrote:
>> On Thu, Mar 22, 2012 at 11:06 PM, Fujii Masao wrote:
>>>
>>> We can use
>>> pg_xlogfile_name function to calculate that, but it cannot be executed in
>>> the standby. Another problem is
On Fri, Mar 23, 2012 at 2:06 PM, Jaime Casanova wrote:
> On Thu, Mar 22, 2012 at 11:06 PM, Fujii Masao wrote:
>>
>> We can use
>> pg_xlogfile_name function to calculate that, but it cannot be executed in
>> the standby. Another problem is that pg_xlogfile_name always uses
>> current timeline for
Thank you for picking up.
> is considering three cases: it got a 2-byte integer (and can continue on),
> or there aren't yet 2 more bytes available in the buffer, in which case it
> should return EOF without doing anything, or pqGetInt detected a hard
> error and updated the connection error state
On Fri, Mar 23, 2012 at 05:06, Fujii Masao wrote:
> Hi,
>
> I'd like to propose to change pg_controldata so that it reports the name
> of WAL file containing the latest checkpoint's REDO record, as follows:
>
> $ pg_controldata $PGDATA
> ...
> Latest checkpoint's REDO location: 0/16D6A
On Fri, Mar 23, 2012 at 12:26 AM, Daniel Farina wrote:
> Some time ago I reported bug 6291[0], which reported a Xid wraparound,
> both as reported in pg_controldata and by txid_current_snapshot.
> Unfortunately, nobody could reproduce it.
>
> Today, the same system of ours just passed the wraparo
62 matches
Mail list logo
