Josh Berkus writes:
>> BTW, has anyone thought through whether this is a sane idea at all?
>> It seems to me to be full of cases that will require rather arbitrary
>> decisions, like whether ON DELETE CASCADE should involve deleting the
>> whole row or just one array element.
> One array element,
On Wed, Nov 16, 2011 at 11:28 PM, Noah Misch wrote:
>
> Removing values from the array seems best to me. There's no doubt about what
> ON UPDATE CASCADE should do, and having ON DELETE CASCADE excise individual
> array elements is consistent with that. It's less clear for SET NULL, but I'd
> con
Folks,
BTW, I don't want to block this patch. However, it occurs to me that a
more generalized FK based on non-equality conditions (i.e. expressions)
would be nice if it were possible. Then we could have FKs from all
kinds of complex structures.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pg
2011/11/17 Tom Lane :
> Noah Misch writes:
>> On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
>>> CREATE TABLE pt (
>>> id INTEGER PRIMARY KEY,
>>>
>>> CREATE TABLE ft (
>>> id SERIAL PRIMARY KEY,
>>> pids INTEGER[] REFERENCES pt,
>
>> I'm assuming the SQL spec says nothing abo
> BTW, has anyone thought through whether this is a sane idea at all?
> It seems to me to be full of cases that will require rather arbitrary
> decisions, like whether ON DELETE CASCADE should involve deleting the
> whole row or just one array element.
One array element, presumably.
Does the pat
Noah Misch writes:
> On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
>> CREATE TABLE pt (
>> id INTEGER PRIMARY KEY,
>>
>> CREATE TABLE ft (
>> id SERIAL PRIMARY KEY,
>> pids INTEGER[] REFERENCES pt,
> I'm assuming the SQL spec says nothing about a feature like this?
I'm pre
On 11/16/11 7:54 PM, Tom Lane wrote:
> Heck, we don't even have a field bug report that the design limitation
> is causing any real problems for real users ... so IMO, the claims that
> this is dangerously broken are a bit overblown.
This is why I mentioned clients using ISBN in production. I hav
On Thu, Nov 17, 2011 at 10:01 AM, Robert Haas wrote:
>
> I am not convinced that that's a better API. I mean, consider
> something like this:
>
> /*
> * OK, let's do it. First let other backends know I'm in ANALYZE.
> */
> LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
> MyProc->v
Hello
2011/11/17 Noah Misch :
> Hi Gabriele,
>
> On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
>> CREATE TABLE pt (
>> id INTEGER PRIMARY KEY,
>> ...
>> );
>>
>> CREATE TABLE ft (
>> id SERIAL PRIMARY KEY,
>> pids INTEGER[] REFERENCES pt,
>> ...
>> );
>
> This seems
On Wed, Nov 16, 2011 at 11:16 PM, Pavan Deolasee
wrote:
> On Tue, Nov 15, 2011 at 7:20 PM, Robert Haas wrote:
>> The lower layer I called "FlexLocks",
>> and it's designed to allow a variety of locking implementations to be
>> built on top of it and reuse as much of the basic infrastructure as I
Hi Gabriele,
On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
> CREATE TABLE pt (
> id INTEGER PRIMARY KEY,
> ...
> );
>
> CREATE TABLE ft (
> id SERIAL PRIMARY KEY,
> pids INTEGER[] REFERENCES pt,
> ...
> );
This seems useful.
I'm assuming the SQL spec says nothing
On Wed, Nov 16, 2011 at 11:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> (I wonder if we shouldn't just align every shared memory allocation to
>> 64 or 128 bytes. It wouldn't waste much memory and it would make us
>> much more resistant to performance changes caused by minor
>> modifications
On Tue, Nov 15, 2011 at 7:20 PM, Robert Haas wrote:
> The lower layer I called "FlexLocks",
> and it's designed to allow a variety of locking implementations to be
> built on top of it and reuse as much of the basic infrastructure as I
> could figure out how to make reusable without hurting perfor
Robert Haas writes:
> (I wonder if we shouldn't just align every shared memory allocation to
> 64 or 128 bytes. It wouldn't waste much memory and it would make us
> much more resistant to performance changes caused by minor
> modifications to the shared memory layout.)
I could get behind this id
Peter Geoghegan writes:
> On 17 November 2011 02:32, Josh Berkus wrote:
>> Right. Do we need to dump the hyphen logic?
> Only if you think that it's better to have something that covers many
> cases but is basically broke. Perhaps it's different for code that is
> already committed, but in the
I wrote:
> PFC, a patch that does this.
Upon further review, this patch would need some more work even for the
RowExpr case, because there are several places that build RowExprs
without bothering to build a valid colnames list. It's clearly soluble
if anyone cares to put in the work, but I'm not
I wrote:
> and the issue seems to be that in execution of a RowExpr, the
> executor doesn't pay any attention to preserving the column names
> in the generated tupledesc --- see the ExecTypeFromExprList call
> in execQual.c. ...
> We could certainly make it do that --- it wouldn't even be terribly
On 17 November 2011 02:32, Josh Berkus wrote:
>
>> (I'm a bit concerned about the angle that the code has some smarts
>> currently about where to put hyphens in output. If we rip that out
>> it could definitely break application code, whereas dropping a check
>> shouldn't.)
>
> Right. Do we need
> (I'm a bit concerned about the angle that the code has some smarts
> currently about where to put hyphens in output. If we rip that out
> it could definitely break application code, whereas dropping a check
> shouldn't.)
Right. Do we need to dump the hyphen logic?
--
Josh Berkus
PostgreSQL
"Andrew Dunstan" writes:
> What I'm having difficulty understanding is why the limit clause should
> make any difference.
Without the LIMIT, the query gets flattened to something like this:
Index Scan using pg_class_oid_index on pg_catalog.pg_class c
(cost=0.00..8.27 rows=1 width=202)
Output
"Andrew Dunstan" writes:
> On Wed, November 16, 2011 6:45 pm, Greg Jaskiewicz wrote:
>> What will happen if I specify:
>> includedir './'
> I would vote for it only to handle plain files (possibly softlinked) in
> the named directory.
I think Greg's point is that that would lead to again reading
On Wed, Nov 16, 2011 at 5:15 PM, Simon Riggs wrote:
> On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas wrote:
>> Taking the median of those five results, the patch seems to have sped
>> things up by 0.3%. At 80 clients:
>
> Thanks for doing that. Even if we fix it as you suggest it seems to
> indica
Dimitri Fontaine writes:
> Peter Eisentraut writes:
>> This is a massive amount of code that very few people in our community
>> will use, and very few be able to maintain it, too.
It's not that "massive", at least not as it stands, although I agree it
looks distressingly write-only.
>> If you
Josh Berkus writes:
> On 11/15/11 7:40 PM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> If we can't put isn out of its misery, a sensible compromise would be
>>> to rip out the prefix enforcement feature so that, for example, ISBN13
>>> behaved exactly the same as EAN13.
>> That might be a rea
On Wed, November 16, 2011 6:45 pm, Greg Jaskiewicz wrote:
>
> On 16 Nov 2011, at 04:53, Greg Smith wrote:
>>
>> -Called by specifying "includedir ". No changes to the
>> shipped postgresql.conf yet.
>> -Takes an input directory name
> Very useful idea.
>
> What will happen if I specify:
>
> includ
I wrote:
> Simon Riggs writes:
>> We need a function called transactionid_current() so a normal user can write
>> select virtualtransaction
>> from pg_locks
>> where transactionid = transactionid_current()
>> and have it "just work".
> That would solve that one specific use-case. The reason I
On 16 Nov 2011, at 04:53, Greg Smith wrote:
>
> -Called by specifying "includedir ". No changes to the shipped
> postgresql.conf yet.
> -Takes an input directory name
Very useful idea.
What will happen if I specify:
includedir './'
Ie, what about potential cyclic dependency.
--
Sent via
I noticed that << and >> are not marked as commutator operators,
though a naive view of their semantics suggests they should be.
However, I realized that there might be edge cases I wasn't thinking
about, so I went looking in the patch to try to confirm this. And
I found neither a single line of d
On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas wrote:
> Taking the median of those five results, the patch seems to have sped
> things up by 0.3%. At 80 clients:
Thanks for doing that. Even if we fix it as you suggest it seems to
indicate that the WALInsertLock contention is real rather than fals
The patch applies cleanly to the current git master and is in context diff format.The patch fails the regression tests because it is outputting new DETAIL line which four of tests aren't expecting. The tests will need to be updated.Functionality:The patch works as advertised. An insert or update
I wrote:
> Why do these use anynonarray rather than anyelement? Given that we
> support ranges of arrays (there's even a regression test), this seems
> a bogus limitation.
After experimenting with changing that, I see why you did it: some of
the regression tests fail, eg,
SELECT * FROM array_i
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wrote:
>
>> Looking for comments ...
>>
>> https://gist.github.com/be937d3a7a5323c73b6e
>>
>> We'd like to get this, or something like it, into 9.2
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wr
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wrote:
>
>> Looking for comments ...
>>
>> https://gist.github.com/be937d3a7a5323c73b6e
>>
>> We'd like to get this, or something like it, into 9.2
>
> If you want it to be seriously considered, you should post the patch
> to
On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat wrote:
> On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith wrote:
> > On 11/15/2011 09:44 AM, Scott Mead wrote:
> >>
> >> Fell off the map last week, here's v2 that:
> >> * RUNNING => active
> >> * all states from CAPS to lower case
> >>
> >
> > This lo
Consider the following query:
select (x).key as k, (x).value as v
from (select each(hstore(q)) as x
from (select oid, c.*
from pg_class c
where oid = 'parent'::regclass) q) t;
This gives results like this:
k | v
-+
f1 | 16410
f2 | parent
f3 |
On Wed, Nov 16, 2011 at 9:33 AM, Robert Haas wrote:
> On Tue, Nov 15, 2011 at 6:24 AM, Simon Riggs wrote:
>> Patch adds cacheline padding around parts of XLogCtl.
>>
>> Idea from way back, but never got performance tested in a situation
>> where WALInsertLock was the bottleneck.
>>
>> So this is
Edward Muller wrote:
> Looking for comments ...
>
> https://gist.github.com/be937d3a7a5323c73b6e
>
> We'd like to get this, or something like it, into 9.2
If you want it to be seriously considered, you should post the patch
to this list, which makes it part of the permanent archives and
indi
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
PS Subscribing to psql-hack...@postgresql.org just spins for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Peter Eisentraut writes:
> This is a massive amount of code that very few people in our community
> will use, and very few be able to maintain it, too. If you want to make
> a lasting contribution on this area, write a program that generates the
> node handling functionality automatically as part
On ons, 2011-11-09 at 20:14 +0100, Dimitri Fontaine wrote:
> The task in $subject is something I will have to do repeatedly for
> completing the Command Trigger patch. I've been doing some of them
> manually, covering initdb. Then I've been scripting away the editing.
>
> The script takes a Node
On 11/15/11 7:40 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> If we can't put isn out of its misery, a sensible compromise would be
>> to rip out the prefix enforcement feature so that, for example, ISBN13
>> behaved exactly the same as EAN13.
>
> That might be a reasonable compromise. Certa
Robert Haas wrote:
> Kevin Grittner wrote:
>> Is there any way to typedef our way out of it [?]
> Well, if we just say:
>
> typedef FlexLockId LWLockId;
>
> ...that's about equivalent to the #define from the compiler's
> point of view.
Bummer -- I was hoping there was some equivalent to "
Why do these use anynonarray rather than anyelement? Given that we
support ranges of arrays (there's even a regression test), this seems
a bogus limitation.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On Wed, Nov 16, 2011 at 11:17 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Now maybe there is some better way to do this, but at the moment,
>> I'm not seeing it. If we call them all LWLocks, but only some of
>> them support LWLockAcquire(), then that's going to be pretty
>> weird.
>
> Is
On Wed, Nov 16, 2011 at 11:14 AM, Greg Stark wrote:
> On Wed, Nov 16, 2011 at 3:41 PM, Robert Haas wrote:
>> Now, you're always going to use
>> LWLockAcquire() and LWLockRelease() to acquire and release an LWLock,
>> but a FlexLockId isn't guaranteed to be an LWLockId - any given value
>> might
Robert Haas wrote:
> Kevin Grittner wrote:
>> This suggests that in the long term, it might be worth [...]
> The other possibility is that the OS is smart enough about moving
> things around to get good locality that sticking locality hints on
> top doesn't really make any difference. Certai
Robert Haas wrote:
> Now maybe there is some better way to do this, but at the moment,
> I'm not seeing it. If we call them all LWLocks, but only some of
> them support LWLockAcquire(), then that's going to be pretty
> weird.
Is there any way to typedef our way out of it, such that a LWLock
On Wed, Nov 16, 2011 at 3:41 PM, Robert Haas wrote:
> Now, you're always going to use
> LWLockAcquire() and LWLockRelease() to acquire and release an LWLock,
> but a FlexLockId isn't guaranteed to be an LWLockId - any given value
> might also refer to a FlexLock of some other type. If we let eve
On Wed, Nov 16, 2011 at 10:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, it would certainly be easy enough to add those macros, and I'm
>> not necessarily opposed to it, but I fear it could end up being a bit
>> confusing in the long run. If we adopt this infrastructure, then I
>> expect
Robert Haas writes:
> Well, it would certainly be easy enough to add those macros, and I'm
> not necessarily opposed to it, but I fear it could end up being a bit
> confusing in the long run. If we adopt this infrastructure, then I
> expect knowledge of different types of FlexLocks to gradually
>
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> I just don't see the reason to do a global search and replace on
>> the lwlock name
> I was going to review further before commenting on that, but since
> it has now come up -- it seems odd that a source file which uses
> only LW locks needs to c
On Wed, Nov 16, 2011 at 10:26 AM, Kevin Grittner
wrote:
> For example, if these two macros were defined, predicate.c wouldn't
> have needed any modifications, and I suspect that is true of many
> other files (although possibly needing a few other macros):
>
> #define LWLockId FlexLockId
> #define
Simon Riggs wrote:
> I just don't see the reason to do a global search and replace on
> the lwlock name
I was going to review further before commenting on that, but since
it has now come up -- it seems odd that a source file which uses
only LW locks needs to change so much for the FlexLock
imp
On Wed, Nov 16, 2011 at 9:20 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> The term “core” here intends to show off that those extensions are
>>> maintained by the core PostgreSQL developer team. If needs be, those
>>> extensions will get updated in minor releases (crash, bugs, security,
The November CommitFest is now closed for new entries. We have 30
patches in the queue that are still looking for a reviewer at this
point, out of a total of 53. If you'd like to review a patch but are
looking for a suggestion as to which to choose, e-mail the
pgsql-rrreviewers list saying so
On Wed, Nov 16, 2011 at 12:28 AM, Greg Smith wrote:
> By recent popular request in the ongoing discussion saga around merging the
> recovery.conf, I've added an "includeifexists" directive to the
> postgresql.conf in the attached patch.
I haven't read the code yet, but just to get the bikesheddin
On Wed, Nov 16, 2011 at 9:47 AM, Kevin Grittner
wrote:
> This suggests that in the long term, it might be worth investigating
> whether we can arrange for a connection's process to have some
> degree of core affinity and encourage each process to allocate local
> memory from RAM controlled by that
Yeb Havinga writes:
> On 2011-11-16 15:34, Tom Lane wrote:
>> The dividing line is enormously unstable though. pgstattuple's idea of
>> RecentGlobalXmin could even be significantly different from that of a
>> concurrently running VACUUM. I can see the point of having VACUUM log
>> what it did, b
On Wed, Nov 16, 2011 at 9:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> Not sure about the log line, but allowing pgstattuple to distinguish
>> between recently-dead and quite-thoroughly-dead seems useful.
>
> The dividing line is enormously unstable though. pgstattuple's idea of
> RecentGloba
On 2011-11-16 15:34, Tom Lane wrote:
Robert Haas writes:
Not sure about the log line, but allowing pgstattuple to distinguish
between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though. pgstattuple's idea of
RecentGlobalXmin could even be sig
On tis, 2011-11-15 at 22:27 -0500, Tom Lane wrote:
> Now, --clean using DROP IF EXISTS would be targeted at, um, what case?
> I guess the idea is to be able to load into a database that sort of
> mostly shares the same schema as the one you dumped from, only it's
> not the same (if it were the same
Euler Taveira de Oliveira writes:
> On 16-11-2011 02:28, Greg Smith wrote:
>> By recent popular request in the ongoing discussion saga around merging the
>> recovery.conf, I've added an "includeifexists" directive to the
>> postgresql.conf in the attached patch.
> I'm not following the merging re
Ants Aasma wrote:
> Concurrency 8 results should probably be ignored - variance was
> huge, definitely more than the differences.
I'm not so sure it should be ignored -- one thing I noticed in
looking at the raw numbers from my benchmarks was that the -O2 code
was much more consistent from run
Hello,
I'm new in postgreSQL programming. I try to print a tuple from
tupleTableSlot structure..
for example..
outerTupleSlot = ExecHashJoinOuterGetTuple(outerNode,
node,
&hashvalue);
how to extract a tuple value?
there are any kind
Robert Haas writes:
> Not sure about the log line, but allowing pgstattuple to distinguish
> between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though. pgstattuple's idea of
RecentGlobalXmin could even be significantly different from that of a
On Tue, Nov 15, 2011 at 6:24 AM, Simon Riggs wrote:
> Patch adds cacheline padding around parts of XLogCtl.
>
> Idea from way back, but never got performance tested in a situation
> where WALInsertLock was the bottleneck.
>
> So this is speculative, in need of testing to investigate value.
I kick
On 16-11-2011 02:28, Greg Smith wrote:
> By recent popular request in the ongoing discussion saga around merging the
> recovery.conf, I've added an "includeifexists" directive to the
> postgresql.conf in the attached patch.
>
I'm not following the merging recovery.conf thread but isn't it worth em
Robert Haas writes:
>> The term “core” here intends to show off that those extensions are
>> maintained by the core PostgreSQL developer team. If needs be, those
>> extensions will get updated in minor releases (crash, bugs, security,
>> etc).
>
> Everything in contrib meets that definition, more
Robert Haas writes:
>> Should I add an item for that in the commit fest?
>
> Sounds like a good idea.
Done: https://commitfest.postgresql.org/action/patch_view?id=707
Note: I might also add support for equalfuncs and copyfuncs while at,
been doing that again and I guess I would just M-x it next
On Tue, Nov 15, 2011 at 8:19 PM, Joshua Berkus wrote:
>> > Here is a patch for that for pg_dump. The sections provided for are
>> > pre-data, data and post-data, as discussed elsewhere. I still feel that
>> > anything finer grained should be handled via pg_restore's --use-list
>> > functionality.
On Tue, Nov 15, 2011 at 5:41 AM, Dimitri Fontaine
wrote:
> Dimitri Fontaine writes:
>> Dimitri Fontaine writes:
>>> What about adding that into src/tools/editors/pgsrc.el?
>
> Should I add an item for that in the commit fest?
Sounds like a good idea.
--
Robert Haas
EnterpriseDB: http://www.en
On Tue, Nov 15, 2011 at 10:02 PM, Royce Ausburn wrote:
> Fair enough -- someone knowledgable could set that up if they wanted. My
> goal was mostly to have something helpful in the logs. If that's not
> something postgres wants/needs Ill drop it =)
IMHO, it's generally not desirable to provid
On Wed, Nov 16, 2011 at 3:31 AM, Yeb Havinga wrote:
> Apparently pg_stat* counts the recently_dead tuple under n_live_tup, else 2
> is a wrong number, where pgstattuple counts recently_dead under
> dead_tuple_count. This could be a source of confusion. If there is any
> serious work considered her
On Tue, Nov 15, 2011 at 5:50 AM, Dimitri Fontaine
wrote:
> Thom Brown writes:
>> None of those others perform such a role. Instead they add additional
>> functionality intended to be utilised as part of general data usage,
>> adding new types, operators, query functions etc. Maybe the term
>> "
Martijn van Oosterhout writes:
> That said, I still don't see how you can enforce a unique index over
> multiple segments over something other than the partition key while
> still allowing quick dropping of segments. If you can fix that you can
> make it work for the current inheritence-style par
Thom Brown writes:
> None of those others perform such a role. Instead they add additional
> functionality intended to be utilised as part of general data usage,
> adding new types, operators, query functions etc. Maybe the term
> "core" is inappropriate. Instead we might wish to refer to them
Dimitri Fontaine writes:
> Dimitri Fontaine writes:
>> What about adding that into src/tools/editors/pgsrc.el?
Should I add an item for that in the commit fest?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (
On Wed, Nov 16, 2011 at 1:17 AM, Robert Haas wrote:
> On Tue, Nov 15, 2011 at 7:18 PM, Jeff Janes wrote:
>> When I apply this to HEAD and run make check, it freezes at:
>> test tablespace ...
> [...]
>> Does anyone else see this?
>
> It hangs for me, too, just slightly later:
OK,
On 2011-11-15 22:04, Tom Lane wrote:
Robert Haas writes:
Oh. I was thinking "dead" meant "no longer visible to anyone". But
it sounds what we call "unremovable" here is what we elsewhere call
"recently dead".
Would have to look at the code to be sure, but I think that
"nonremovable" is mean
On Tue, Nov 15, 2011 at 8:33 PM, Alvaro Herrera
wrote:
>> > I'm not really enthused by the idea of completely rewriting lwlocks
>> > for this. Seems like specialised code is likely to be best, as well as
>> > having less collateral damage.
>>
>> Well, the problem that I have with that is that we'
80 matches
Mail list logo
