Re: [HACKERS] Explicit psqlrc

Simon Riggs wrote: > On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote: > > On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote: > > > On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote: > > >> A further point is that it's very difficult to > > >> keep track of progress if the CF page reflects

Re: [HACKERS] MERGE Specification

On 10/08/10 06:03, Boxuan Zhai wrote: I have put everything in one patch, against the latest git repository. The program is tested on my machine. Thanks! I get a few compiler warnings: analyze.c: In function ‘transformMergeStmt’: analyze.c:2476: warning: unused variable ‘lastaction’ gram.y: In

Re: [HACKERS] Explicit psqlrc

Kevin Grittner wrote: > > We should be giving authors as much leeway as possible, or they > > may not come back. > > One phenomenon I've noticed is that sometimes a patch is submitted > because an end user has solved their own problem for themselves, but > wishes to share the solution with the co

Re: [HACKERS] TODO 9.0 done items removed

Andrew Dunstan wrote: > > > On 08/09/2010 09:36 PM, Tom Lane wrote: > > "David E. Wheeler" writes: > >> On Aug 9, 2010, at 5:45 PM, Bruce Momjian wrote: > >>> I figured it out; done: > >>> http://wiki.postgresql.org/wiki/TodoDone90 > >> Jeepers. That's a long list! > > Uh, there seems to be qui

Re: [HACKERS] TODO 9.0 done items removed

Tom Lane wrote: > "David E. Wheeler" writes: > > On Aug 9, 2010, at 5:45 PM, Bruce Momjian wrote: > >> I figured it out; done: > >> http://wiki.postgresql.org/wiki/TodoDone90 > > > Jeepers. That's a long list! > > Uh, there seems to be quite a lot there that is *not* done in 9.0. > In fact, non

Re: [HACKERS] host name support in pg_hba.conf

On mån, 2010-08-09 at 15:25 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Here is a patch for host name support in pg_hba.conf. > > My recollection is that the previous discussions got stuck on the cost > of doing DNS lookups for every connect; and the obvious solution of > trying to cach

Re: [HACKERS] host name support in pg_hba.conf

On mån, 2010-08-09 at 23:01 +0200, Kristian Larsson wrote: > In which order are things evaluated? What if I only include IP > addresses in my pg_hba, will it still cost me a DNS lookup or > two? No, if you don't use this feature, it won't cost you anything. -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] host name support in pg_hba.conf

On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote: > Peter Eisentraut wrote: > > > The client's IP address (known from the kernel) > > Some machines have several IP addresses; how is that handled? A connection comes in over exactly one address. > > is reverse looked up, which results

Re: [HACKERS] host name support in pg_hba.conf

On mån, 2010-08-09 at 15:05 -0400, Robert Haas wrote: > -1 from me, on this part. I think we should be trying to eliminate > any dependencies we have on how localhost resolves, and we certainly > should not add more. Maybe this is something that distributors could add if they have more knowledge

Re: [HACKERS] grouping sets - updated patch

2010/8/10 Joshua Tolley : > On Mon, Aug 09, 2010 at 10:59:26PM +0200, Pavel Stehule wrote: >> Hello >> >> I fixed an issues with empty sets. It just work, but there are some ugly >> hacks. >> >> It's really needs own planner node - now grouping functions are not >> supported by ORDER BY clause. >

Re: [HACKERS] grouping sets - updated patch

On Mon, Aug 09, 2010 at 10:59:26PM +0200, Pavel Stehule wrote: > Hello > > I fixed an issues with empty sets. It just work, but there are some ugly > hacks. > > It's really needs own planner node - now grouping functions are not > supported by ORDER BY clause. I haven't made it through the last

Re: [HACKERS] Universal B-tree

There is a way to acess a index inside a c function without using a sql statement ? Best regards, Daniel Oliveira 2010/8/9 Daniel Oliveira > For research purpose, I think that expression index is a good idea. I just > want to do a proof of concept. > > The other issue is that my algorithm brea

[HACKERS] 1-byte id for SharedInvalidationMessages

On Fri, Aug 6, 2010 at 2:43 PM, Tom Lane wrote: >> Do you think it's worth worrying about the reduction in the number of >> possible SI message types? > > IIRC the number of message types is the number of catalog caches plus > half a dozen or so.  We're a long way from exhausting even a 1-byte > I

Re: [HACKERS] TODO 9.0 done items removed

On 08/09/2010 09:36 PM, Tom Lane wrote: "David E. Wheeler" writes: On Aug 9, 2010, at 5:45 PM, Bruce Momjian wrote: I figured it out; done: http://wiki.postgresql.org/wiki/TodoDone90 Jeepe

Re: [HACKERS] TODO 9.0 done items removed

"David E. Wheeler" writes: > On Aug 9, 2010, at 5:45 PM, Bruce Momjian wrote: >> I figured it out; done: >> http://wiki.postgresql.org/wiki/TodoDone90 > Jeepers. That's a long list! Uh, there seems to be quite a lot there that is *not* done in 9.0. In fact, none of the first page's worth are do

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 7:17 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Aug 9, 2010 at 4:18 PM, Tom Lane wrote: >>> Particular implementations might cope with such cases in useful ways, or >>> then again they might not. >> That doesn't seem like a big problem to me.  I was assuming we'd

Re: [HACKERS] TODO 9.0 done items removed

On Aug 9, 2010, at 5:45 PM, Bruce Momjian wrote: > I figured it out; done: > > http://wiki.postgresql.org/wiki/TodoDone90 Jeepers. That's a long list! David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 9:44 PM, Robert Haas wrote: > That doesn't seem like a big problem to me.  I was assuming we'd need > to remap when the size changed. I had thought about this in the past too, just for supporting run-time changes to shared_buffers. I always assumed we would just allocate sh

Re: [HACKERS] TODO 9.0 done items removed

> Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of sb jul 17 21:21:52 -0400 > > 2010: > > > Since we branched 9.1 before we released Postgres 9.0, I had to remove > > > the 9.0 TODO items before 9.0 was released, or people might have marked > > > items as "done" when they were do

[HACKERS] RecordTransactionCommit() and SharedInvalidationMessages

It appears to me that RecordTransactionCommit() only needs to WAL-log shared invalidation messages when wal_level is hot_standby, but I don't see a guard to prevent it from doing it in all cases. Am I missing something? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Post

Re: [HACKERS] knngist - 0.8

On Mon, Aug 09, 2010 at 06:35:47PM -0300, Euler Taveira de Oliveira wrote: > Alexander Korotkov escreveu: > > Such approach can give benefit when we need to filter by > > similarity. For example, in pg_trgm "%" is used for similarity > > filtering, but similarity threshold is global for session. Th

Re: [HACKERS] security label support, part.2

2010/8/9 : >> 2. Some of this code refers to "local" security labels.  I'm not sure >> what's "local" about them - aren't they just security labels?  On a >> related note, I don't like the trivial wrappers you have here, with >> DeleteSecurityLabel around DeleteLocalSecLabel, SetSecurityLabel >> a

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas writes: > On Mon, Aug 9, 2010 at 4:18 PM, Tom Lane wrote: >> Particular implementations might cope with such cases in useful ways, or >> then again they might not. > That doesn't seem like a big problem to me. I was assuming we'd need > to remap when the size changed. Well, as long

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

On Tue, 2010-08-10 at 07:43 +0900, Itagaki Takahiro wrote: > 2010/8/10 Simon Riggs : > > Any SQL statement that reads a block can do HOT pruning, if the block is > > otherwise unlocked. > > We use the term "HOT" for two features: > 1. HOT updates: Avoiding index updates when keys are not modifie

Re: [HACKERS] SHOW TABLES

Bruce Momjian wrote: > Kevin Grittner wrote: >> I can't picture anything which could be done with views which >> would allow me to issue one statement and see everything of >> interest about a table (etc.). You know: tablespace, owner, >> permissions, columns, primary key, foreign keys, check >

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

2010/8/10 Simon Riggs : > Any SQL statement that reads a block can do HOT pruning, if the block is > otherwise unlocked. We use the term "HOT" for two features: 1. HOT updates: Avoiding index updates when keys are not modified. 2. HOT pruning: Removing tuple bodies, that works even for indexed

Re: [HACKERS] SHOW TABLES

Kevin Grittner wrote: > Stefan Kaltenbrunner wrote: > > On 07/18/2010 08:58 PM, Andres Freund wrote: > > >> I am quite a bit surprised about all this discussion. I have a > >> very hard time we will find anything people agree about and can > >> remember well enough to be usefull for both manual

[HACKERS] new client release

There is a new release of the buildfarm client. There are no new features, but some cleanup and bug fixes. The code can be downloaded from: Here are the release notes / change log: . Use git clean to remove build products left

Re: [HACKERS] security label support, part.2

Thanks for your reviewing. On Mon, 9 Aug 2010 16:02:12 -0400 Robert Haas wrote: > 2010/7/26 KaiGai Kohei : > > The attached patches are revised ones, as follows. > > I think this is pretty good, and I'm generally in favor of committing > it. Some concerns: > > 1. Since nobody has violently ob

Re: [HACKERS] SHOW TABLES

On Mon, Aug 9, 2010 at 5:42 PM, Bruce Momjian wrote: > Sorry for the late reply.  If we are going to end up recreating SQL, we > might as well just keep the backslash mess we have, or tell them to use > SQL for the complex queries.  My point was that we might find that what > we cook up is as comp

Re: [HACKERS] SHOW TABLES

On Mon, 2010-08-09 at 17:42 -0400, Bruce Momjian wrote: > Robert Haas wrote: > > On Sat, Jul 17, 2010 at 11:14 PM, Bruce Momjian wrote: > > > Robert Haas wrote: > > >> I'd like to be able to list comments on objects of a particular type. > > >> And, yeah, I'd like to be able to list all the aggreg

Re: [HACKERS] patch: to_string, to_array functions

Hello 2010/8/9 Tom Lane : > Brendan Jurd writes: >>> I have attached v4 of the patch against HEAD, and also an incremental >>> patch showing just my changes against v3. >>> >>> I'll mark this as ready for committer. > > Looking at this, I want to question the implode/explode naming.  I think > th

Re: [HACKERS] SHOW TABLES

Robert Haas wrote: > On Sat, Jul 17, 2010 at 11:14 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> I'd like to be able to list comments on objects of a particular type. > >> And, yeah, I'd like to be able to list all the aggregates that take a > >> numeric argument, or all the functions that

Re: [HACKERS] patch: to_string, to_array functions

David E. Wheeler wrote: > On Aug 9, 2010, at 1:10 PM, Robert Haas wrote: > > >> My first thought is that we should go back to the string_to_array and > >> array_to_string names. The key reason not to use those names was the > >> conflict with the old functions if you didn't specify a third argume

Re: [HACKERS] knngist - 0.8

Alexander Korotkov escreveu: > Such approach > can give benefit when we need to filter by similarity. For example, in > pg_trgm "%" is used for similarity filtering, but similarity threshold > is global for session. That's why we can't create complex queries which > contain similarity filtering wit

Re: [HACKERS] Synchronous replication

Fujii Masao wrote: > On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas > wrote: > > Then you risk running out of disk space. Similar to having an archive > > command that fails for some reason. > > > > That's one reason the registration should not be too automatic - there is > > serious repercus

Re: [HACKERS] host name support in pg_hba.conf

On Mon, Aug 09, 2010 at 03:25:23PM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Here is a patch for host name support in pg_hba.conf. > > My recollection is that the previous discussions got stuck on the cost > of doing DNS lookups for every connect; and the obvious solution of > trying

Re: [HACKERS] Synchronous replication

I wonder if we can continue to rely on the pg_sleep() loop for sleeping in walsender. On those platforms where interrupts don't interrupt sleep, sending the signal is not going to promptly wake up walsender. That was fine before, but any delay is going to be poison to synchronous replication pe

Re: [HACKERS] Synchronous replication

On 01/08/10 15:30, Greg Stark wrote: On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas wrote: I don't think any of this quorum stuff makes much sense without explicitly registering standbys in the master. This doesn't have to be done manually. The streaming protocol could include the standb

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 09, 2010 at 02:16:47PM -0400, Robert Haas wrote: > I believe I went back and reread > the old threads on this topic and it seems like the sticking point as > far as POSIX shm goes it that it lacks a readable equivalent of > shm_nattch. I think it was proposed to use a small syv shm and

Re: [HACKERS] Synchronous replication

On 05/08/10 17:14, Fujii Masao wrote: I'm thinking to make users register and unregister each standbys via SQL functions like register_standby() and unregister_standby(): The register/unregister facility should be accessible from the streaming replication connection, so that you don't need to

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 4:18 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote: >>> It's not portable.  That's exactly what we were looking into back when. > >> Uggh, that sucks.  Can you provide any more details? > > You don't really have to go further t

Re: [HACKERS] patch: to_string, to_array functions

On Mon, Aug 9, 2010 at 4:34 PM, Tom Lane wrote: > Merlin Moncure writes: >> Is there any reason why array functions need the type prefix when >> other type conversion functions don't?  Why didn't we name unnest() >> array_unnest()? > > UNNEST() is in the standard, IIRC, so you'd have to ask the S

Re: [HACKERS] patch: to_string, to_array functions

On Aug 9, 2010, at 1:10 PM, Robert Haas wrote: >> My first thought is that we should go back to the string_to_array and >> array_to_string names. The key reason not to use those names was the >> conflict with the old functions if you didn't specify a third argument, >> but where is the advantage

Re: [HACKERS] patch: to_string, to_array functions

Merlin Moncure writes: > Is there any reason why array functions need the type prefix when > other type conversion functions don't? Why didn't we name unnest() > array_unnest()? UNNEST() is in the standard, IIRC, so you'd have to ask the SQL committee that. (And no, they're not exactly being co

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas wrote: > I don't think it's going to be too easy to provide, short of (as > Tom says) moving to the MySQL model of many threads working in a > single process. Well, it's a bit misleading to refer to it as the MySQL model. It's used by Microsoft SQL Server, MySQL, Informix, and Syb

[HACKERS] Hector Beyers wants to stay in touch on LinkedIn

LinkedIn Hector Beyers souhaite se connecter à vous sur LinkedIn : -- Amine, I'd like to add you to my professional network on LinkedIn. - Hector Beyers Accepter l'invitation de Hector Beyers http://www.linkedin.com/e/cm7uxn-gcns21oh-6h/VWCdri

Re: [HACKERS] patch: to_string, to_array functions

On Mon, Aug 9, 2010 at 4:08 PM, Tom Lane wrote: > Brendan Jurd writes: >>> I have attached v4 of the patch against HEAD, and also an incremental >>> patch showing just my changes against v3. >>> >>> I'll mark this as ready for committer. > > Looking at this, I want to question the implode/explode

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas writes: > On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote: >> It's not portable.  That's exactly what we were looking into back when. > Uggh, that sucks. Can you provide any more details? You don't really have to go further than consulting the relevant standards, eg SUS says at http

Re: [HACKERS] patch: to_string, to_array functions

On Mon, Aug 9, 2010 at 4:08 PM, Tom Lane wrote: > Brendan Jurd writes: >>> I have attached v4 of the patch against HEAD, and also an incremental >>> patch showing just my changes against v3. >>> >>> I'll mark this as ready for committer. > > Looking at this, I want to question the implode/explode

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote: >>> ... and on some platforms, it'll be flat out impossible.  We looked at >>> this years ago and concluded that changing the size of the shmem segment >>> after postmaster s

Re: [HACKERS] patch: to_string, to_array functions

Brendan Jurd writes: >> I have attached v4 of the patch against HEAD, and also an incremental >> patch showing just my changes against v3. >> >> I'll mark this as ready for committer. Looking at this, I want to question the implode/explode naming. I think those names are too cute by half, not p

Re: [HACKERS] security label support, part.2

2010/7/26 KaiGai Kohei : > The attached patches are revised ones, as follows. I think this is pretty good, and I'm generally in favor of committing it. Some concerns: 1. Since nobody has violently objected to the comment.c refactoring patch I recently proposed, I'm hopeful that can go in. And i

Re: [HACKERS] host name support in pg_hba.conf

* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: > > The client's IP address (known from the kernel) > > Some machines have several IP addresses; how is that handled? Sounds like he already described it, or I read it wrong. The fact that some machines have several IP addresses hardly matte

Re: [HACKERS] dynamically allocating chunks from shared memory

Hi, On 08/09/2010 09:14 PM, Tom Lane wrote: As far as SLRU is concerned, the already-agreed-to plan is to get rid of the separate arenas for SLRU and merge those things into the main shared buffers arena. I didn't know about that plan. Sounds good. (I'm personally thinking this is trying to s

Re: [HACKERS] host name support in pg_hba.conf

Peter Eisentraut writes: > Here is a patch for host name support in pg_hba.conf. My recollection is that the previous discussions got stuck on the cost of doing DNS lookups for every connect; and the obvious solution of trying to cache the names was shot down on the basis of not knowing when to f

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas writes: > On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote: >> ... and on some platforms, it'll be flat out impossible.  We looked at >> this years ago and concluded that changing the size of the shmem segment >> after postmaster start was impractical from a portability standpoint. >>

Re: [HACKERS] dynamically allocating chunks from shared memory

Markus Wanner writes: > However, I'd like to get back to the original intent of the posted > patch. Which is about dynamically allocating memory *within a fixed size > pool*. > That's something SRLU or shared_buffers do to some extent, but with lots > of limitations. And without the ability to

Re: [HACKERS] dynamically allocating chunks from shared memory

Hi, On 08/09/2010 08:45 PM, Robert Haas wrote: Yeah, I think that's a real concern. I think we need to distinguish memory needs from memory wants. Ideally, we'd like our entire database to be cached in RAM. But that may or may not be feasible, so we page what we can into shared_buffers and pa

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 3:00 PM, Bruce Momjian wrote: >> That would be one way to tackle the problem, but there are >> difficulties.  If we just created new shared memory segments at need, >> we might end up with a lot of shared memory segments.  I suspect that >> would get complicated and present

Re: [HACKERS] dynamically allocating chunks from shared memory

On 08/09/2010 09:00 PM, Bruce Momjian wrote: You could allocate shared memory in chunks and then pass that out to requestors, the same way sbrk() does it. sbrk() is described [1] as a "low-level memory allocator", which "is typically only used by the high-level malloc memory allocator impleme

Re: [HACKERS] host name support in pg_hba.conf

On Mon, Aug 9, 2010 at 2:47 PM, Peter Eisentraut wrote: > Here is a patch for host name support in pg_hba.conf.  I have reviewed > various past threads about this, and there appeared to have been a 50/50 > split of for and against reverse lookup.  I went with the reverse > lookup, because > > 0) I

Re: [HACKERS] dynamically allocating chunks from shared memory

On 08/09/2010 08:50 PM, Bruce Momjian wrote: You effectively have to add infrastructure to add/remove shared memory segments to match memory requests. It is another step, but it is the same behavior. That's of no use without a dynamic allocator, I think. Or else it is a vague description of a

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas wrote: > On Mon, Aug 9, 2010 at 2:50 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote: > >> >> > Let me be more concrete. ?Suppose you are using threads, and you want > >> >> > to > >> >> > increase your shared memory from 20MB

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 2:50 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote: >> >> > Let me be more concrete. ?Suppose you are using threads, and you want to >> >> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If >> >>

Re: [HACKERS] dynamically allocating chunks from shared memory

On 08/09/2010 08:49 PM, Bruce Momjian wrote: Markus Wanner wrote: That's what my patch allows you to do, yes. Currently you are bound to pre-allocate shared memory at startup. Or how would you allocate small chunks from shared memory at the moment? We don't --- we allocate it all at startup.

Re: [HACKERS] host name support in pg_hba.conf

On 9 August 2010 19:47, Peter Eisentraut wrote: > Here is a patch for host name support in pg_hba.conf.  I have reviewed > various past threads about this, and there appeared to have been a 50/50 > split of for and against reverse lookup.  I went with the reverse > lookup, because > > 0) I like it

Re: [HACKERS] host name support in pg_hba.conf

Peter Eisentraut wrote: > The client's IP address (known from the kernel) Some machines have several IP addresses; how is that handled? > is reverse looked up, which results in a host name. Some IP addresses have several host names, including in reverse lookup; how is that handled? -Kevi

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas wrote: > On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote: > >> > Let me be more concrete. ?Suppose you are using threads, and you want to > >> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If > >> > you want it contiguous, you have to use realloc, which mig

Re: [HACKERS] dynamically allocating chunks from shared memory

Markus Wanner wrote: > On 08/09/2010 08:33 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> You probably wouldn't do either of those things. You'd just allocate > >> small chunks here and there for whatever you need them for. > > > > Well, then we do that with shared memory then --- my point i

Re: [HACKERS] [JDBC] Trouble with COPY IN

On Sat, 7 Aug 2010, Kris Jurka wrote: On Fri, 6 Aug 2010, James William Pye wrote: I think there's a snag in the patch: postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY; ERROR: row field count is -1, expected 1 CONTEXT: COPY data, line 4 Probably a quick/small fix away, I im

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote: >> > Let me be more concrete. ?Suppose you are using threads, and you want to >> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If >> > you want it contiguous, you have to use realloc, which might move the >> > pointer. ?

[HACKERS] host name support in pg_hba.conf

Here is a patch for host name support in pg_hba.conf. I have reviewed various past threads about this, and there appeared to have been a 50/50 split of for and against reverse lookup. I went with the reverse lookup, because 0) I like it. 1) It is more secure. 2) It allows extending it to wildc

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 2:28 PM, Markus Wanner wrote: > Another issue to be discussed would be the limits of sharing free memory > between subsystems. Maybe we even reach the conclusion that we absolutely > *want* fixed maximum sizes for every single subsystem so as to be able to > guarantee a cert

Re: [HACKERS] dynamically allocating chunks from shared memory

On 08/09/2010 08:33 PM, Bruce Momjian wrote: Robert Haas wrote: You probably wouldn't do either of those things. You'd just allocate small chunks here and there for whatever you need them for. Well, then we do that with shared memory then --- my point is that it is the same problem with threa

Re: [HACKERS] dynamically allocating chunks from shared memory

Markus Wanner wrote: > Hi, > > On 08/09/2010 06:31 PM, Bruce Momjian wrote: > > Let me be more concrete. Suppose you are using threads, and you want to > > increase your shared memory from 20MB to 30MB. How do you do that? > > There's absolutely no need to pre-allocate 20 MB in advance in a >

Re: [HACKERS] dynamically allocating chunks from shared memory

Robert Haas wrote: > On Mon, Aug 9, 2010 at 12:31 PM, Bruce Momjian wrote: > > Bruce Momjian wrote: > >> > With our process-based design, the default is private memory (i.e. not > >> > shared). If you need shared memory, you must specify a certain amount in > >> > advance. That chunk of shared mem

Re: [HACKERS] dynamically allocating chunks from shared memory

Markus Wanner wrote: > Hi, > > On 08/09/2010 06:10 PM, Bruce Momjian wrote: > > My point is that you can treat malloc the same as "add shared memory", > > to some extent, with the same limiations. > > Once one of the SLRU buffers is full, it cannot currently allocate from > another SLRU buffer's

Re: [HACKERS] knngist - 0.8

On Sun, Aug 8, 2010 at 4:28 PM, Alexander Korotkov wrote: > In gist consitent method support only filtering strategies. For such > strategies consistent method returns true if subtree can contain matching > node and false otherwise. Knngist introduce also order by strategies. For > filtering strat

Re: [HACKERS] dynamically allocating chunks from shared memory

Hi, On 08/09/2010 06:31 PM, Bruce Momjian wrote: Let me be more concrete. Suppose you are using threads, and you want to increase your shared memory from 20MB to 30MB. How do you do that? There's absolutely no need to pre-allocate 20 MB in advance in a threaded environment. You just allocat

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

On Mon, Aug 9, 2010 at 2:23 PM, Heikki Linnakangas wrote: > On 09/08/10 21:21, Robert Haas wrote: >> >> On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs  wrote: >>> >>> Any SQL statement that reads a block can do HOT pruning, if the block is >>> otherwise unlocked. >> >> Where does heap_page_prune() ge

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

On 09/08/10 21:21, Robert Haas wrote: On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs wrote: Any SQL statement that reads a block can do HOT pruning, if the block is otherwise unlocked. Where does heap_page_prune() get called from in the DELETE path? heapgetpage() -- Heikki Linnakangas Ent

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs wrote: > On Sat, 2010-08-07 at 16:11 -0700, Gordon Shannon wrote: > >> So, I guess my real question here is, what happened to the "missing" >> 100 items?  If it was HOT prune, can anyone summarize what that does? > > Itagaki already explained that the se

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 12:31 PM, Bruce Momjian wrote: > Bruce Momjian wrote: >> > With our process-based design, the default is private memory (i.e. not >> > shared). If you need shared memory, you must specify a certain amount in >> > advance. That chunk of shared memory then is reserved and can'

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 12:03 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian wrote: >> > I am not sure threads would greatly help us. ?The major problem is that >> > all of our our structures are currently contiguous in memory for quick >> > access.

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote: > Robert Haas writes: >> So imagine that thread-or-process A allocates allocates a new chunk of >> memory and then writes a pointer to the new chunk in a previously >> allocated section of memory.  Thread-or-process B then follows the >> pointer.  

Re: [HACKERS] dynamically allocating chunks from shared memory

Hi, On 08/09/2010 06:10 PM, Bruce Momjian wrote: My point is that you can treat malloc the same as "add shared memory", to some extent, with the same limiations. Once one of the SLRU buffers is full, it cannot currently allocate from another SLRU buffer's unused memory area. That memory there

Re: [HACKERS] dynamically allocating chunks from shared memory

Hi, On 08/09/2010 05:41 PM, Tom Lane wrote: ... and on some platforms, it'll be flat out impossible. We looked at this years ago and concluded that changing the size of the shmem segment after postmaster start was impractical from a portability standpoint. I have not seen anything to change tha

Re: [HACKERS] is syntax columname(tablename) necessary still?

2010/8/9 Robert Haas : > On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule > wrote: >>> They name to be type_func_keywords, perhaps, but not fully reserved. >>> And they'd still need that treatment anyway.  Even if cube(whatever) >>> can't mean "extract a column called cube from table whatever", it

Re: [HACKERS] is syntax columname(tablename) necessary still?

On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule wrote: >> They name to be type_func_keywords, perhaps, but not fully reserved. >> And they'd still need that treatment anyway.  Even if cube(whatever) >> can't mean "extract a column called cube from table whatever", it can >> still mean "call a funct

Re: [HACKERS] Surprising dead_tuple_count from pgstattuple

On Sat, 2010-08-07 at 16:11 -0700, Gordon Shannon wrote: > So, I guess my real question here is, what happened to the "missing" > 100 items? If it was HOT prune, can anyone summarize what that does? Itagaki already explained that the second DELETE would have removed the 100 dead rows you conside

Re: [HACKERS] dynamically allocating chunks from shared memory

On Mon, 2010-08-09 at 11:41 -0400, Tom Lane wrote: > Robert Haas writes: > > So imagine that thread-or-process A allocates allocates a new chunk of > > memory and then writes a pointer to the new chunk in a previously > > allocated section of memory. Thread-or-process B then follows the > > point

Re: [HACKERS] Universal B-tree

For research purpose, I think that expression index is a good idea. I just want to do a proof of concept. The other issue is that my algorithm break a z-order interval into several intervals that represents the query box. How should I create it without creating any overhead? Best regards, daniel

Re: [HACKERS] knngist - 0.8

In gist consitent method support only filtering strategies. For such strategies consistent method returns true if subtree can contain matching node and false otherwise. Knngist introduce also order by strategies. For filtering strategies knngist consistent method returns 0 if subtree can contain m

Re: [HACKERS] patch: to_string, to_array functions

Apparently, the message I sent (quoted below) didn't make it to -hackers. I know that Pavel received the message, as he replied to it. I'm calling shenanigans on the mailing list server, but in the meantime, here are those diffs again. On 31 July 2010 07:37, Brendan Jurd wrote: > Hi Pavel, > >

Re: [HACKERS] Universal B-tree

On Mon, Aug 9, 2010 at 5:31 PM, Daniel Oliveira wrote: > I don't need to change B-tree estructure. I just need integrate my encode > function that transforms multiple keys into one key by bit-interleaving and > to acess elements given several intervals (range search). You could build a "expressio

Re: [HACKERS] patch: to_string, to_array functions

Pavel Stehule wrote: > 2010/7/21 Itagaki Takahiro : > > 2010/7/20 Pavel Stehule : > >> here is a new version - new these functions are not a strict and > >> function to_string is marked as stable. > > > > We have array_to_string(anyarray, text) and string_to_array(text, text), > > and you'll introd

Re: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Dave Page writes: > >>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that > >>> be the case, or is it something else? > >> > >> He's mistaken. The bug is in all the branches, but there have been no > >> releases

Re: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs

Bruce Momjian writes: > Tom Lane wrote: >> Dave Page writes: >>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that >>> be the case, or is it something else? >> >> He's mistaken. The bug is in all the branches, but there have been no >> releases with it except 9.0beta3. I wil

Re: [HACKERS] dynamically allocating chunks from shared memory

Bruce Momjian wrote: > > With our process-based design, the default is private memory (i.e. not > > shared). If you need shared memory, you must specify a certain amount in > > advance. That chunk of shared memory then is reserved and can't ever be > > used by another subsystem. Even if you bare

  1   2   >