On 30.11.2010 06:57, Robert Haas wrote:
I can't say I'm totally in love with any of these designs. Anyone
else have any ideas, or any opinions about which one is best?
Well, the design I've been pondering goes like this:
At vacuum:
1. Write an "intent" XLOG record listing a chunk of visibili
On Monday 29 November 2010 19:10:07 Tom Lane wrote:
> Jeff Janes writes:
> > Are you sure you haven't just moved the page-fault time to a part of
> > the code where it still exists, but just isn't being captured and
> > reported?
>
> I'm a bit suspicious about that too. Another thing to keep in
On Tue, Nov 30, 2010 at 05:09, Jaime Casanova wrote:
> at least IMHO the only sensible way that LIMIT is usefull is with
> an ORDER BY clause with make the results very well defined...
DELETE with LIMIT is also useful for deleting things in batches, so
you can do large deletes on a live system wi
On Mon, Nov 29, 2010 at 11:25 PM, Andrew Dunstan wrote:
>
>
> On 11/29/2010 10:19 PM, Robert Haas wrote:
>
> For example, suppose we're trying to govern an ancient Greek
> democracy:
>
> http://en.wikipedia.org/wiki/Ostracism
>
> DELETE FROM residents_of_athens ORDER BY ostracism_votes DESC LIMIT
Last week, I posted a couple of possible designs for making the
visibility map crash-safe, which did not elicit much comment. Since
this is an important prerequisite to index-only scans, I'm trying
again.
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01474.php
http://archives.postgresql
On 11/29/2010 10:19 PM, Robert Haas wrote:
For example, suppose we're trying to govern an ancient Greek
democracy:
http://en.wikipedia.org/wiki/Ostracism
DELETE FROM residents_of_athens ORDER BY ostracism_votes DESC LIMIT 1;
I'm not sure this is a very good example. Assuming there isn't
Greg Stark wrote:
> On Mon, Nov 29, 2010 at 12:33 AM, Tom Lane wrote:
> > The most portable way to do that would be to use calloc insted of malloc,
> > and hope that libc is smart enough to provide freshly-mapped space.
> > It would be good to look and see whether glibc actually does so,
> > of co
On Tue, Nov 30, 2010 at 08:56, Alvaro Herrera
wrote:
>> > * I hope pg_execute_from_file (and pg_read_file) had an option
>> > to specify an character encoding of the file. Especially, SJIS
>> > is still used widely, but it is not a valid server encoding.
>>
>> So, what about client_encoding he
On Mon, Nov 29, 2010 at 10:09 PM, Jaime Casanova wrote:
> On Mon, Nov 29, 2010 at 9:55 PM, Daniel Loureiro wrote:
>> good point. But when you use a LIMIT in a SELECT statement you WANT n RANDOM
>> tuples
>
> no. at least IMHO the only sensible way that LIMIT is usefull is with
> an ORDER BY claus
On Tue, Nov 30, 2010 at 05:03, Dimitri Fontaine wrote:
> I believe v6 fixes it all, please find it attached.
>
>> Design and Implementation
>> * pg_execute_from_file() can execute any files even if they are not
>> in $PGDATA. OTOH, we restrict pg_read_file() to read such files.
>> Wh
On Mon, Nov 29, 2010 at 9:08 PM, Daniel Loureiro wrote:
> frequently i have accidents with DELETE/UPDATE commands. In fact, sometimes
> in the last 8 or 9 years (ok, a lot of times) I forget the entire WHERE
> clause or have a “not so perfectly“ WHERE clause, with an awful suprise.
> There’s no wo
On Mon, Nov 29, 2010 at 9:55 PM, Daniel Loureiro wrote:
> good point. But when you use a LIMIT in a SELECT statement you WANT n RANDOM
> tuples
no. at least IMHO the only sensible way that LIMIT is usefull is with
an ORDER BY clause with make the results very well defined...
--
Jaime Casanova
On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote:
>> It seems to me that if we're really worried about which locks users
>> are allowed to take (and so far all of the worrying seems to lack a
>> solid basis in any sort of usability argument) we'd need to invent
>> some special-purpose permi
Yes, thanks, those are reasonable goals.
---
Daniel Farina wrote:
> On Wed, Nov 24, 2010 at 7:21 PM, Bruce Momjian wrote:
> > What are we adding a pl/pgsql dependency for? ?What is the benefit that
> > will warrant requirin
good point. But when you use a LIMIT in a SELECT statement you WANT n RANDOM
tuples - its wrong to get RANDOM tuples ? So, in the same logic, its wrong
to exclude n random tuples ? Besides, if you want DELETE just 1 tuple, why
the executor have to scan the entire table, and not just stoping after f
On Mon, Nov 29, 2010 at 10:50 AM, Robert Haas wrote:
> A user with single-column UPDATE privileges could obtain a ROW
> EXCLUSIVE lock by issuing an UPDATE statement, but currently cannot
> obtain the same lock using LOCK TABLE. It would be reasonable and
> consistent to allow such a user to take
On Mon, Nov 29, 2010 at 9:08 PM, Daniel Loureiro wrote:
>
> 3) change the executor to stop after “n” successful iterations. Is
> this correct ?
>
no. it means you will delete the n first tuples that happen to be
found, if you don't have a WHERE clause that means is very possible
you delete someth
On Tue, Nov 30, 2010 at 01:01, queej wrote:
> I have views that use the dblink(connStr text, sql text) call. They cannot
> use a two-step process. So postgres 9.0 has broken all of those views. Is
> there a straightforward solution to this?
Could you explain your views? I cannot get any warni
Hi,
frequently i have accidents with DELETE/UPDATE commands. In fact, sometimes
in the last 8 or 9 years (ok, a lot of times) I forget the entire WHERE
clause or have a “not so perfectly“ WHERE clause, with an awful suprise.
There’s no words to figure the horror ever time i see that the number of
Robert Haas wrote:
> On Sun, Nov 28, 2010 at 7:15 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> One possible way to get a real speedup here would be to look for ways
> >> to trim the number of catcaches.
> >
> > BTW, it's not going to help to remove catcaches that have a small
> > initial size
Tom Lane wrote:
> BTW, this might be premature to mention pending some tests about mapping
> versus zeroing overhead, but it strikes me that there's more than one
> way to skin a cat. I still think the idea of statically allocated space
> sucks. But what if we rearranged things so that palloc0 do
Robert Haas wrote:
> In a close race, I don't think we should get bogged down in
> micro-optimization here, both because micro-optimizations may not gain
> much and because what works well on one platform may not do much at
> all on another. The more general issue here is what to do about our
> hi
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian wrote:
> >> Not sure that information moves us forward. ?If the postmaster cleared
> >> the memory, we would have COW in the child and probably be even slower.
>
> > Well, we can determine the answers to th
I have views that use the dblink(connStr text, sql text) call. They cannot
use a two-step process. So postgres 9.0 has broken all of those views. Is
there a straightforward solution to this?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/dblink-versus-long-connection
Excerpts from Dimitri Fontaine's message of lun nov 29 17:03:06 -0300 2010:
> Itagaki Takahiro writes:
> > * I hope pg_execute_from_file (and pg_read_file) had an option
> > to specify an character encoding of the file. Especially, SJIS
> > is still used widely, but it is not a valid server e
I wrote:
> I applied all three patches with minor offsets, and it builds, but
> several regression tests fail.
Sorry, after sending that I realized I hadn't done a make distclean.
After that it passes. Please ignore the previous post.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-ha
Andres Freund wrote:
> Ok, I implemented that capability
I applied all three patches with minor offsets, and it builds, but
several regression tests fail. I backed out the patches in reverse
order and confirmed that while the regression tests pass without
any of these patches, they fail with
Excerpts from Tom Lane's message of lun nov 29 18:33:19 -0300 2010:
> Alvaro Herrera writes:
> > Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
> >> Additionally, we'd have to expend some more cycles at the parse analysis
> >> phase (of the "FOR SHARE OF x.col1, x.col2"
Alvaro Herrera writes:
> Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
>> Additionally, we'd have to expend some more cycles at the parse analysis
>> phase (of the "FOR SHARE OF x.col1, x.col2" query) to verify that those
>> columns belong into some non-partial unique i
On Mon, Nov 29, 2010 at 02:09:29PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Mon, Nov 29, 2010 at 16:26, Robert Haas wrote:
> >> That works for me. �But should we make a practice of writing the
> >> ENTIRE SHA-ID rather than an abbreviated form, so that we could more
> >> easily rep
Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
> This would require some additions in ri_FetchConstraintInfo(). Right
> now it does a single syscache lookup and then extracts a bunch of
> attributes from there. If we're going to implement as you suggest, we'd
> have to
Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
> To me, the whole thing seems to be special case of allowing to not only lock
> whole tuples FOR UPDATE or FOR SHARE, but also individual fields or sets of
> fields. Except that for simplicity, only two sets are supported,
Heikki Linnakangas wrote:
> Maybe invent a short name for PredLockTranList and/or the fields?
Done:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=44c8f221100b87fc7c23425f53f2fd38d735b7d2
> I'd suggest a union field.
Done:
http://git.postgresql.org/gitweb?
On 29.11.2010 07:11, Joachim Wieland wrote:
On Mon, Nov 22, 2010 at 3:44 PM, Heikki Linnakangas
wrote:
* wrap long lines
* use extern in function prototypes in header files
* "inline" some functions like _StartDataCompressor, _EndDataCompressor,
_DoInflate/_DoDeflate that aren't doing anythin
Itagaki Takahiro writes:
> I have some comments and questions about
> pg_execute_from_file.v5.patch.
I believe v6 fixes it all, please find it attached.
> Source code
> * OID=3627 is used by another function. Don't you expect 3927?
>
> * There is a compiler warning:
> genfile.c: In f
On Mon, Nov 29, 2010 at 2:26 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> How do you test this feature?
>
> Try src/tools/ifaddrs/test_ifaddrs.c. I think the only usage in the
> core code is testing samehost/samenet matches in pg_hba.conf.
It looks like this is unfortunately more involved.
Merlin Moncure writes:
> How do you test this feature?
Try src/tools/ifaddrs/test_ifaddrs.c. I think the only usage in the
core code is testing samehost/samenet matches in pg_hba.conf.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Mon, Nov 29, 2010 at 1:38 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> PostgreSQL 9 is breaking for me on line 654 of ip.c. ip.c is checking
>> on presence SIOCGLIFCONF to determine if it's ok to use linux method
>> of polling if addrs etc over ioctl, which is not enough. hpux provides
>>
On 11/29/2010 01:30 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/29/2010 12:36 PM, Robert Haas wrote:
But that could equally well be stored in a user table rather than a
system table.
Yeah. The trouble is you won't be able to use that reliably in a check
constraint, which I imagine is o
Excerpts from Florian Pflug's message of sáb nov 27 01:29:39 -0300 2010:
> On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> > The problem with this idea is that it's not possible to implement it.
>
> How so? The implementation you proposed in your blog should work fine for
> this. XMAX_KEY_LOC
Magnus Hagander writes:
> On Mon, Nov 29, 2010 at 16:26, Robert Haas wrote:
>> That works for me. But should we make a practice of writing the
>> ENTIRE SHA-ID rather than an abbreviated form, so that we could more
>> easily replace 'em later if need be?
> I think that's a good idea.
Just as a
On Mon, Nov 29, 2010 at 16:26, Robert Haas wrote:
> On Mon, Nov 29, 2010 at 7:45 AM, Magnus Hagander wrote:
>>> Let's do both: "This fixes the bug introduced by the foobar patch from Sep
>>> 12th (git commitid a2c23897bc).
>>>
>>> I like to see the date of the referred patch in the commit message
Merlin Moncure writes:
> PostgreSQL 9 is breaking for me on line 654 of ip.c. ip.c is checking
> on presence SIOCGLIFCONF to determine if it's ok to use linux method
> of polling if addrs etc over ioctl, which is not enough. hpux provides
> this method in similar fashion, but the structs are name
Andrew Dunstan writes:
> On 11/29/2010 12:36 PM, Robert Haas wrote:
>> But that could equally well be stored in a user table rather than a
>> system table.
> Yeah. The trouble is you won't be able to use that reliably in a check
> constraint, which I imagine is one of the principal intended purp
PostgreSQL 9 is breaking for me on line 654 of ip.c. ip.c is checking
on presence SIOCGLIFCONF to determine if it's ok to use linux method
of polling if addrs etc over ioctl, which is not enough. hpux provides
this method in similar fashion, but the structs are named different,
and have different
On Mon, Nov 29, 2010 at 12:56 PM, Andrew Dunstan wrote:
> On 11/29/2010 12:36 PM, Robert Haas wrote:
>> On Mon, Nov 29, 2010 at 12:18 PM, Pavel Stehule
>> wrote:
>>> 2010/11/29 Robert Haas:
On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil
wrote:
> I have idea of creating system tabl
On Mon, Nov 29, 2010 at 12:50 PM, Tom Lane wrote:
> (On the last two machines I had to cut the array size to 256MB to avoid
> swapping.)
You weren't kidding about that "not so recent" part. :-)
>> This makes me pretty
>> pessimistic about the chances of a meaningful speedup here.
>
> Yeah, this
Jeff Janes writes:
> Are you sure you haven't just moved the page-fault time to a part of
> the code where it still exists, but just isn't being captured and
> reported?
I'm a bit suspicious about that too. Another thing to keep in mind
is that Robert's original program doesn't guarantee that th
On 11/29/2010 12:36 PM, Robert Haas wrote:
On Mon, Nov 29, 2010 at 12:18 PM, Pavel Stehule wrote:
2010/11/29 Robert Haas:
On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil wrote:
I have idea of creating system table for holding DTDs, XSDs, Relax-NGs (similar
as on ORACLE).
Is that good ide
2010/11/29 Robert Haas :
> On Mon, Nov 29, 2010 at 12:18 PM, Pavel Stehule
> wrote:
>> 2010/11/29 Robert Haas :
>>> On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil wrote:
I have idea of creating system table for holding DTDs, XSDs, Relax-NGs
(similar as on ORACLE).
Is that g
Robert Haas writes:
> I guess the word "run" is misleading (I wrote the program in 5
> minutes); it's just zeroing the same chunk twice and measuring the
> times. The difference is presumably the page fault overhead, which
> implies that faulting is two-thirds of the overhead on MacOS X and
> thr
On Mon, Nov 29, 2010 at 9:24 AM, Andres Freund wrote:
> On Monday 29 November 2010 17:57:51 Robert Haas wrote:
>> On Sun, Nov 28, 2010 at 11:51 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Yeah, very true. What's a bit frustrating about the whole thing is
>> >> that we spend a lot of time
On Monday 29 November 2010 18:34:02 Robert Haas wrote:
> On Mon, Nov 29, 2010 at 12:24 PM, Andres Freund wrote:
> > Hm. A quick test shows that its quite a bit faster if you allocate memory
> > with:
> > size_t s = 512*1024*1024;
> > char *bss = mmap(0, s, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_POP
On Mon, Nov 29, 2010 at 12:18 PM, Pavel Stehule wrote:
> 2010/11/29 Robert Haas :
>> On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil wrote:
>>> I have idea of creating system table for holding DTDs, XSDs, Relax-NGs
>>> (similar as on ORACLE).
>>>
>>> Is that good idea?
>>
>> I doubt it. Why wou
On Mon, Nov 29, 2010 at 12:21 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I'd pick pg_execute_from_file() and just plain pg_execute(), myself.
>
> For the record there's only one name exposed at the SQL level. Or do you
> want me to expand the patch to actually include a pg_execute() ver
On Mon, Nov 29, 2010 at 12:24 PM, Andres Freund wrote:
> Hm. A quick test shows that its quite a bit faster if you allocate memory
> with:
> size_t s = 512*1024*1024;
> char *bss = mmap(0, s, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_POPULATE|
> MAP_ANONYMOUS, -1, 0);
Numbers?
--
Robert Haas
Enterp
On Monday 29 November 2010 17:57:51 Robert Haas wrote:
> On Sun, Nov 28, 2010 at 11:51 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Yeah, very true. What's a bit frustrating about the whole thing is
> >> that we spend a lot of time pulling data into the caches that's
> >> basically static an
Robert Haas writes:
> I'd pick pg_execute_from_file() and just plain pg_execute(), myself.
For the record there's only one name exposed at the SQL level. Or do you
want me to expand the patch to actually include a pg_execute() version
of the function, that would execute the query in PG_GETARG_TEX
2010/11/29 Robert Haas :
> On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil wrote:
>> I have idea of creating system table for holding DTDs, XSDs, Relax-NGs
>> (similar as on ORACLE).
>>
>> Is that good idea?
>
> I doubt it. Why would we want to do that?
If I understand, it allows a local copy o
"Hamza Bin Sohail" wrote:
> I was wondering if I could get to know whether Postgres
> administrators configure the Postgres DBMS with large page support
> for shared memory regions
You might be interested in a recent thread in the -hackers archives
which starts with this post:
http://archive
On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil wrote:
> I have idea of creating system table for holding DTDs, XSDs, Relax-NGs
> (similar as on ORACLE).
>
> Is that good idea?
I doubt it. Why would we want to do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
On Mon, Nov 29, 2010 at 12:05 PM, Hamza Bin Sohail wrote:
> 1) Does Postgres use large page support ? On solaris 10 and the ultrasparc
> III processor, a large page is 4 MB. It significantly reduces the page table
> size of the application and a 1000 entry TLB can cover the entire memory 4G.
>
> 2
Hi,
I posted this email on the other postgres lists but did not get a reply. So as
a last resort, I came here. I hope somebody can help.
I am looking into the impact of large page sizes on the performance of
commercial workloads e.g databases,webserver,virtual machines etc. I was
wondering if
On Sun, Nov 28, 2010 at 11:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, very true. What's a bit frustrating about the whole thing is
>> that we spend a lot of time pulling data into the caches that's
>> basically static and never likely to change anywhere, ever.
>
> True. I wonder if w
On Mon, Nov 29, 2010 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> pg_execute_file() could be read to mean you are going to execute the
>> file itself (i.e. it's a program).
>
> Well, if that's what it suggests to you, I don't see how adding "from"
> disambiguates anything. You could be
Robert Haas writes:
> pg_execute_file() could be read to mean you are going to execute the
> file itself (i.e. it's a program).
Well, if that's what it suggests to you, I don't see how adding "from"
disambiguates anything. You could be executing machine code "from"
a file, too.
What did you thi
On Mon, Nov 29, 2010 at 11:12 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm not sure why you need either "from". It just seems like a noise
>> word. Maybe we could use pg_execute_query_file() and
>> pg_execute_query_string(), which would be fairly clear and nicely
>> symmetrical.
>
> +1, bu
Andrew Dunstan writes:
> On 11/29/2010 11:12 AM, Tom Lane wrote:
>> +1, but I think "query" is also a noise word here.
>> Why not just "pg_execute_file" and "pg_execute_string"?
> Well, I put that in to make it clear that the file/string is expected to
> contain SQL and not, say, machine code. B
On 11/29/2010 11:12 AM, Tom Lane wrote:
Andrew Dunstan writes:
I'm not sure why you need either "from". It just seems like a noise
word. Maybe we could use pg_execute_query_file() and
pg_execute_query_string(), which would be fairly clear and nicely
symmetrical.
+1, but I think "query" is al
On Mon, Nov 29, 2010 at 11:12:58AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > I'm not sure why you need either "from". It just seems like a noise
> > word. Maybe we could use pg_execute_query_file() and
> > pg_execute_query_string(), which would be fairly clear and nicely
> > symmetric
On 11/29/2010 10:51 AM, Robert Haas wrote:
I'm not sure why you need either "from". It just seems like a noise word.
Maybe we could use pg_execute_query_file() and pg_execute_query_string(),
which would be fairly clear and nicely symmetrical.
Because you execute queries, not files. Or at lea
Andrew Dunstan writes:
> I'm not sure why you need either "from". It just seems like a noise
> word. Maybe we could use pg_execute_query_file() and
> pg_execute_query_string(), which would be fairly clear and nicely
> symmetrical.
+1, but I think "query" is also a noise word here.
Why not just
On Mon, Nov 29, 2010 at 10:49 AM, Heikki Linnakangas
wrote:
> On 29.11.2010 07:11, Joachim Wieland wrote:
>>
>> On Mon, Nov 22, 2010 at 3:44 PM, Heikki Linnakangas
>> wrote:
>>>
>>> * wrap long lines
>>> * use extern in function prototypes in header files
>>> * "inline" some functions like _Star
On Mon, Nov 29, 2010 at 10:30 AM, Jonathan Corbet wrote:
> On Sat, 27 Nov 2010 14:27:12 -0500
> Tom Lane wrote:
>
>> And the bottom line is: if there's any performance benefit at all,
>> it's on the order of 1%. The best result I got was about 3200 TPS
>> with hugepages, and about 3160 without.
On Mon, Nov 29, 2010 at 10:37 AM, Andrew Dunstan wrote:
>
>
> On 11/29/2010 10:30 AM, Robert Haas wrote:
>>
>> On Mon, Nov 29, 2010 at 10:27 AM, Robert Haas
>> wrote:
>>>
>>> On Mon, Nov 29, 2010 at 4:26 AM, Dimitri Fontaine
>>> wrote:
>
> * I'd like to ask native speakers whether "from
2010/11/28 KaiGai Kohei :
>>> My comment was from a standpoint which wants consistent behavior
>>> between SELECT ... FOR and LOCK command.
>>
>> Again, nothing about this makes those consistent.
>>
>>> If we concerned about this
>>> behavior, ExecCheckRTEPerms() might be a place where we also shou
On 29.11.2010 07:11, Joachim Wieland wrote:
On Mon, Nov 22, 2010 at 3:44 PM, Heikki Linnakangas
wrote:
* wrap long lines
* use extern in function prototypes in header files
* "inline" some functions like _StartDataCompressor, _EndDataCompressor,
_DoInflate/_DoDeflate that aren't doing anythin
Andrew Dunstan writes:
> I'm not sure why you need either "from". It just seems like a noise
> word. Maybe we could use pg_execute_query_file() and
> pg_execute_query_string(), which would be fairly clear and nicely
> symmetrical.
I'd go with that but need to tell: only pg_execute_query_file() is
On 11/29/2010 10:30 AM, Robert Haas wrote:
On Mon, Nov 29, 2010 at 10:27 AM, Robert Haas wrote:
On Mon, Nov 29, 2010 at 4:26 AM, Dimitri Fontaine
wrote:
* I'd like to ask native speakers whether "from" is needed in names
of "pg_execute_from_file" and "pg_execute_from_query_string".
Fai
Jonathan Corbet writes:
> Just a quick note: I can't hazard a guess as to why you're not getting
> better results than you are, but I *can* say that putting together a
> production-quality patch may not be worth your effort regardless. There
> is a nice "transparent hugepages" patch set out there
On Sat, 27 Nov 2010 14:27:12 -0500
Tom Lane wrote:
> And the bottom line is: if there's any performance benefit at all,
> it's on the order of 1%. The best result I got was about 3200 TPS
> with hugepages, and about 3160 without. The noise in these numbers
> is more than 1% though.
>
> This is
On Mon, Nov 29, 2010 at 10:27 AM, Robert Haas wrote:
> On Mon, Nov 29, 2010 at 4:26 AM, Dimitri Fontaine
> wrote:
>>> * I'd like to ask native speakers whether "from" is needed in names
>>> of "pg_execute_from_file" and "pg_execute_from_query_string".
>>
>> Fair enough, will wait for some comme
On Mon, Nov 29, 2010 at 4:26 AM, Dimitri Fontaine
wrote:
>> * I'd like to ask native speakers whether "from" is needed in names
>> of "pg_execute_from_file" and "pg_execute_from_query_string".
>
> Fair enough, will wait for some comments before producing a v6.
Yes, you need the from there.
--
On Mon, Nov 29, 2010 at 7:45 AM, Magnus Hagander wrote:
>> Let's do both: "This fixes the bug introduced by the foobar patch from Sep
>> 12th (git commitid a2c23897bc).
>>
>> I like to see the date of the referred patch in the commit message, to get
>> an immediate idea of whether it was a 5-year
Excerpts from Tom Lane's message of dom ago 15 22:54:31 -0400 2010:
> I'm thinking that we need some sort of what-to-do-on-error flag passed
> into RelationTruncate, plus at least order-of-operations fixes in
> several other places, if not a wholesale refactoring of this whole call
> stack. But I
Excerpts from Pavel Stehule's message of sáb nov 27 04:46:08 -0300 2010:
> Hello
>
> do you plan do some work on this job?
>
Not currently :-(
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgs
Excerpts from Quan Zongliang's message of sáb nov 27 06:03:12 -0300 2010:
> Hi, all
>
> I created a pg_ctl patch to fix:
> * BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
> Allow pg_ctl to work properly with configuration files located outside the
> PGDATA directory
I
On Mon, Nov 29, 2010 at 13:42, Heikki Linnakangas
wrote:
> On 28.11.2010 06:59, Robert Haas wrote:
>>
>> On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
On Nov 27, 2010, at 2:49 PM, Bruce Momjian wrote:
>
> Who's going to be the first to say that b
On 28.11.2010 06:59, Robert Haas wrote:
On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane wrote:
Robert Haas writes:
On Nov 27, 2010, at 2:49 PM, Bruce Momjian wrote:
Who's going to be the first to say that being git-centric can't ever be
a bad thing? ;-)
At least for me, referring to it that w
On 28.11.2010 23:44, Kevin Grittner wrote:
(1) Should these be moved to ShmemVariableCache, or is it OK to
leave them in this structure as long as I comment it adequately?
If they're only used by predicate.c, it seems better to leave them where
they are.
(2) Would it be a good idea to creat
Robert Haas writes:
>> Well, the lack of extensible XLOG support is definitely a big handicap
>> to building a *production* index AM as an add-on. But it's not such a
>> handicap for development.
>
> Realistically, it's hard for me to imagine that anyone would go to the
> trouble of building it a
Itagaki Takahiro writes:
> I have some comments and questions about pg_execute_from_file.v5.patch.
Thanks for reviewing it!
> Source code
> * OID=3627 is used by another function. Don't you expect 3927?
Yes indeed. It took me some time to understand what's happening here,
and it seems
On 29.11.2010 10:43, Christoph Berg wrote:
here's a trivial patch:
Changed several occurrences of ",..." to ", ..." in SQL syntax to be
consistent with the rest.
Thanks, applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql
Hi,
here's a trivial patch:
Changed several occurrences of ",..." to ", ..." in SQL syntax to be
consistent with the rest.
diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml
b/doc/src/sgml/ref/alter_default_privileges.sgml
index e1aa293..c27466f 100644
*** a/doc/src/sgml/ref/alter_defau
94 matches
Mail list logo
