Re: [HACKERS] Range Types, discrete and/or continuous

On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote: > Jeff Davis writes: > > Last development cycle, one of the questions that was unresolved > > was whether to handle ranges like a discrete set (that is, [1,5) = > > [1,4] ) or continuous or both. > > Put me in the camp that says you need b

Re: [HACKERS] Simplifying replication

On Sat, Oct 23, 2010 at 2:34 AM, Josh Berkus wrote: > When we get close enough to max_wal_size (we'll need a couple segments of > leeway, I think), we start recycling WAL segments even if they are less that > min_wal_time old. What happens if max_wal_size is less than checkpoint_segments? Current

Re: [HACKERS] ask for review of MERGE

On Sun, Oct 24, 2010 at 7:11 PM, Greg Stark wrote: > On Sun, Oct 24, 2010 at 2:50 AM, Martijn van Oosterhout > wrote: >> Can we please not get MERGE hung up on trying to make it atomic. The >> standard requires no such thing and there are plenty of uses of MERGE >> that don't involve high concurr

Re: [HACKERS] Range Types, discrete and/or continuous

On Sun, Oct 24, 2010 at 6:59 PM, Tom Lane wrote: > Jeff Davis writes: >> Last development cycle, one of the questions that was unresolved was >> whether to handle ranges like a discrete set (that is, [1,5) = [1,4] ) >> or continuous or both. > > Put me in the camp that says you need both.  I real

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 10/24/2010 09:34 PM, Tom Lane wrote: For both trigger and non-trigger functions, we compile this ahead of the user-set function code: our $_TD; local $_TD=shift; Non-trigger functions get passed "undef" to correspond to this invisible argument, while trigger functions get passed the h

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 09:20 PM, Tom Lane wrote: Andrew Dunstan writes: On 10/24/2010 08:12 PM, Tom Lane wrote: This shows that the bitmapset optimization really is quite effective, at least for cases where all the enum labels are sorted by OID after all. That motivated me to change the bitmapset se

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

Andrew Dunstan writes: > On 10/24/2010 07:50 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> Why do we need the is_trigger flag at all for the plperl hash key? At >>> first glance it strikes me as unnecessary. >> We might not. Does the presence or absence of the $_TD hash reference >> have an

Re: [HACKERS] Extensions, this time with a patch

Itagaki Takahiro writes: > On Sat, Oct 23, 2010 at 5:26 AM, Josh Berkus wrote: >>> Yeah - what is the feasibility of cleaning up the things where there >>> are naming inconsistencies right now? >> >> Easy.  Heck, the only reason we didn't do it 2 years ago was that we >> were waiting for extens

Re: [HACKERS] WIP: extensible enums

Andrew Dunstan writes: > On 10/24/2010 08:12 PM, Tom Lane wrote: >> This shows that the bitmapset optimization really is quite effective, >> at least for cases where all the enum labels are sorted by OID after >> all. That motivated me to change the bitmapset setup code to what's >> attached. Th

Re: [HACKERS] Extensions, this time with a patch

On Sat, Oct 23, 2010 at 5:26 AM, Josh Berkus wrote: >> Yeah - what is the feasibility of cleaning up the things where there >> are naming inconsistencies right now? > > Easy.  Heck, the only reason we didn't do it 2 years ago was that we > were waiting for extensions before bothering. We could re

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 08:12 PM, Tom Lane wrote: OK, I did some timing consisting of building a btree index with maintenance_work_mem set reasonably high. This is on a debug-enabled build, so it's not representative of production performance, but it will do for seeing what we're doing to enum compariso

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 10/24/2010 07:50 PM, Tom Lane wrote: Andrew Dunstan writes: On 10/24/2010 06:44 PM, Tom Lane wrote: I'm not certain that plperl is actually correct to do it that way, but that's the basic idea. Why do we need the is_trigger flag at all for the plperl hash key? At first glance it strikes

Re: [HACKERS] WIP: extensible enums

Andrew Dunstan writes: > On 10/24/2010 05:34 PM, Tom Lane wrote: >> BTW, I've forgotten --- did anyone publish a test case for checking >> performance of enum comparisons? Or should I just cons up something >> privately? > I have been running tests with >

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

Andrew Dunstan writes: > On 10/24/2010 06:44 PM, Tom Lane wrote: >> I'm not certain that plperl is actually correct to do it that way, >> but that's the basic idea. > Why do we need the is_trigger flag at all for the plperl hash key? At > first glance it strikes me as unnecessary. We might not.

Re: [HACKERS] Serializable snapshot isolation patch

Jeff Davis wrote: > On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote: >>> 3. Limited shared memory space to hold information about >>> committed transactions that are still "interesting". >>> It's a challenging problem, however, and the current solution is >>> less than ideal. >> >> I

Re: [HACKERS] ask for review of MERGE

On Sun, Oct 24, 2010 at 2:39 PM, Greg Smith wrote: > Sure, but in the most common use case I think we're targeting at first, no > indexes means there's also no unique constraints either.  I don't think > people can reasonable expect to MERGE or anything else to guarantee they > won't accidentally

Re: [HACKERS] ask for review of MERGE

On Sun, Oct 24, 2010 at 2:50 AM, Martijn van Oosterhout wrote: > Can we please not get MERGE hung up on trying to make it atomic. The > standard requires no such thing and there are plenty of uses of MERGE > that don't involve high concurrency updates of the same row by > different processes. If w

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 10/24/2010 06:44 PM, Tom Lane wrote: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: I see that plperl uses a triple of (function oid, is_trigger flag, user id) as a hash key for caching compiled functions. OTOH pltcl and plpgsql both use (oid, trigger relation oid, user id). Is there any reason

Re: [HACKERS] Range Types, discrete and/or continuous

Jeff Davis writes: > Last development cycle, one of the questions that was unresolved was > whether to handle ranges like a discrete set (that is, [1,5) = [1,4] ) > or continuous or both. Put me in the camp that says you need both. I really seriously dislike the idea of representing [1, 2) as [1

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > I see that plperl uses a triple of (function oid, is_trigger flag, user > id) as a hash key for caching compiled functions. OTOH pltcl and plpgsql > both use (oid, trigger relation oid, user id). Is there any reason why > just using a bool as plperl does

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 05:34 PM, Tom Lane wrote: BTW, I've forgotten --- did anyone publish a test case for checking performance of enum comparisons? Or should I just cons up something privately? I have been running tests with The table "my

[HACKERS] Range Types, discrete and/or continuous

I'd like to open the discussion for Range Types again. This is a fairly long email because several issues are intertwined, and I don't think they can be neatly pulled apart. Previous discussions: http://archives.postgresql.org/pgsql-hackers/2009-12/msg01162.php http://archives.postgresql.org/p

Re: [HACKERS] ask for review of MERGE

Robert Haas wrote: Well, there's no guarantee that any index at all exists on the target table, so any solution based on index locks can't be fully general. Sure, but in the most common use case I think we're targeting at first, no indexes means there's also no unique constraints either. I

[HACKERS] why does plperl cache functions using just a bool for is_trigger

I see that plperl uses a triple of (function oid, is_trigger flag, user id) as a hash key for caching compiled functions. OTOH pltcl and plpgsql both use (oid, trigger relation oid, user id). Is there any reason why just using a bool as plperl does would be wrong? I'm trying to write a validator f

Re: [HACKERS] WIP: extensible enums

BTW, I've forgotten --- did anyone publish a test case for checking performance of enum comparisons? Or should I just cons up something privately? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] [BUGS] Segfault in 9.0 inlining SRF

On 25 October 2010 07:36, Tom Lane wrote: > Looks like the invalItems list has been clobbered: > > (gdb) p *root->glob->invalItems > $6 = {type = 2139062143, length = 2139062143, head = 0x7f7f7f7f, >  tail = 0x7f7f7f7f} > > I'm guessing it was modified in the temporary memory context and not > pro

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 05:09 PM, Andrew Dunstan wrote: select enum_oid, row_number() over () as sort_order from unnest(null::myenum) as enum_oid Of course, I meant: select enum_label, row_number() over () as sort_order from unnest(enum_range(null::myenum)) as enum_label cheers and

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 03:28 PM, Tom Lane wrote: This patch isn't committable as-is because I haven't made enum_first, enum_last, enum_range follow these coding rules: they need to stop using the syscache and instead use an indexscan on pg_enum_typid_sortorder_index to locate the relevant rows. That s

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 03:33 PM, Tom Lane wrote: Dean Rasheed writes: The point with an OID array is that you wouldn't need to store the enumsortorder values at all. The sort order would just be the index of the OID in the array. So the comparison code would read the OID array, traverse it building an

Re: [HACKERS] typenameTypeId refactoring

Peter Eisentraut writes: > Here is a first patch to slightly refactor the type and typmod lookups > with the aim of making it easier to possibly changing the nature or > representation of typmods in the future and making it easier to merge > the collation patch. The comment for typenameTypeIdAndM

Re: [HACKERS] [BUGS] Segfault in 9.0 inlining SRF

Brendan Jurd writes: > I have encountered a reproducible segfault in Postgres, and confirmed > it in 9.0.1 and HEAD on three separate machines. The bug was not > present in 8.4. I've attached a copy of the SQL script I have been > using to induce the segfault. > ... > I had a go at investigating

[HACKERS] Segfault in 9.0 inlining SRF

Hi folks, I have encountered a reproducible segfault in Postgres, and confirmed it in 9.0.1 and HEAD on three separate machines. The bug was not present in 8.4. I've attached a copy of the SQL script I have been using to induce the segfault. With asserts enabled, I get a failed assertion: TRAP

[HACKERS] typenameTypeId refactoring

Here is a first patch to slightly refactor the type and typmod lookups with the aim of making it easier to possibly changing the nature or representation of typmods in the future and making it easier to merge the collation patch. I split the typenameTypeId function into two. Most call sites only

Re: [HACKERS] WIP: extensible enums

Dean Rasheed writes: > The point with an OID array is that you wouldn't need to store the > enumsortorder values at all. The sort order would just be the index of > the OID in the array. So the comparison code would read the OID array, > traverse it building an array of enum_sort structs {oid, idx

Re: [HACKERS] xlog.c: WALInsertLock vs. WALWriteLock

> I'm writing a function that will read data from the buffer in xlog > > (i.e. from XLogCtl->pages and XLogCtl->xlblocks). I want to make > > sure that I am doing it correctly. > > Got an example of what the function might look like? > Say something like this: bool ReadLogFromBuffer(char *buf,

Re: [HACKERS] ask for review of MERGE

On Sun, Oct 24, 2010 at 12:15 PM, Greg Smith wrote: > Robert Haas wrote: >> I am also wondering exactly what the semantics are supposed to be >> under concurrency.  We can't assume that it's OK to treat WHEN NOT >> MATCHED as WHEN MATCHED if a unique-key violation is encountered.  The >> join cond

Re: [HACKERS] WIP: extensible enums

On 24 October 2010 17:20, Tom Lane wrote: > Greg Stark writes: >> There's nothing magic about the integral types here. If you use a >> string then you could always split by making the string longer. > > The entire objective here is to make enum comparisons fast.  Somehow, > going to a non-primiti

Re: [HACKERS] WIP: extensible enums

On 10/24/2010 12:20 PM, Tom Lane wrote: With float4 the implementation would fail at somewhere around 2^24 elements in an enum (since even with renumbering, there wouldn't be enough bits to give each element a distinguishable value). I don't see that as a real objection, and anyway if you wer

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

> > Yeah, my concern is not whether the overhead will be zero; it's > whether it will be small, yet allow large gains on other operations. > Like, how much slower will it be to pull out a moderately complex 1MB > JSON blob (not just a big string) out of a single-row, single-column > table? If it's

Re: [HACKERS] PostgreSQL and HugePage

Hsien-Wen Chu writes: > as my known, FreeBSD implements this feature called superpage, it's similar > with Solaris, so is it enabled in default? or any default parameter need to > be set? The Solaris-specific code is just that if SHM_SHARE_MMU is defined (by , I think) we include it in the flags

Re: [HACKERS] WIP: extensible enums

Greg Stark writes: > There's nothing magic about the integral types here. If you use a > string then you could always split by making the string longer. The entire objective here is to make enum comparisons fast. Somehow, going to a non-primitive data type to represent the sort values does not s

Re: [HACKERS] ask for review of MERGE

Robert Haas wrote: I am also wondering exactly what the semantics are supposed to be under concurrency. We can't assume that it's OK to treat WHEN NOT MATCHED as WHEN MATCHED if a unique-key violation is encountered. The join condition could be something else entirely. I guess we could scan th

Re: [HACKERS] planner row-estimates for tsvector seems horribly wrong

Thanks a ton Jan! It works quite correctly. But many tsearch tutorials ask tsquery to be placed in 'from' statement and that can cause bad plan. Isn't it possible to return the correct number for a join with the query as well? -Sushant. On Sun, 2010-10-24 at 15:07 +0200, Jan Urbański wrote: > On

Re: [HACKERS] planner row-estimates for tsvector seems horribly wrong

On 24/10/10 14:44, Sushant Sinha wrote: > I am using gin index on a tsvector and doing basic search. I see the > row-estimate of the planner to be horribly wrong. It is returning > row-estimate as 4843 for all queries whether it matches zero rows, a > medium number of rows (88,000) or a large numbe

Re: [HACKERS] planner row-estimates for tsvector seems horribly wrong

On 24/10/10 14:44, Sushant Sinha wrote: > I am using gin index on a tsvector and doing basic search. I see the > row-estimate of the planner to be horribly wrong. It is returning > row-estimate as 4843 for all queries whether it matches zero rows, a > medium number of rows (88,000) or a large numbe

[HACKERS] planner row-estimates for tsvector seems horribly wrong

I am using gin index on a tsvector and doing basic search. I see the row-estimate of the planner to be horribly wrong. It is returning row-estimate as 4843 for all queries whether it matches zero rows, a medium number of rows (88,000) or a large number of rows (726,000). The table has roughly a mi

Re: [HACKERS] knngist - 0.8

2010/10/22 Teodor Sigaev : >> You can define the additional argument as providing all of the extra >> info about how the operator is being used, and, if it's being used for >> ordering, the details of the requested order.  What is your thinking >> on the matter? > > Maby be useful, but it seems to

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Sun, Oct 24, 2010 at 2:21 AM, Terry Laurenzo wrote: >> It doesn't do particularly well on my previous example of [1,2,3].  It >> comes out slightly shorter on ["a","b","c"] and better if the strings >> need any escaping.  I don't think the float4 and float8 formats are >> very useful; how could

Re: [HACKERS] ask for review of MERGE

On Sun, Oct 24, 2010 at 5:50 AM, Martijn van Oosterhout wrote: > On Sat, Oct 23, 2010 at 03:59:13PM -0700, Greg Stark wrote: >> I think the blocker with MERGE has always been that the standard is >> *so* general that it could apply to conditions that *aren't* covered >> by a unique constraint or e

Re: [HACKERS] WIP: extensible enums

On 24 October 2010 05:26, Tom Lane wrote: > Well, the easy way to read a consistent view of the world is to load the > cache using an MVCC snapshot instead of SnapshotNow.  The current code > structure isn't amenable to that because it's relying on a syscache to > fetch the data for it, but that s

Re: [HACKERS] PostgreSQL and HugePage

as my known, FreeBSD implements this feature called superpage, it's similar with Solaris, so is it enabled in default? or any default parameter need to be set? Many thank Hsien-Wen On Wed, Oct 20, 2010 at 10:10 PM, Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 19, 2010 at 11:30 PM, d

Re: [HACKERS] ask for review of MERGE

On Sat, Oct 23, 2010 at 03:59:13PM -0700, Greg Stark wrote: > I think the blocker with MERGE has always been that the standard is > *so* general that it could apply to conditions that *aren't* covered > by a unique constraint or exclusion constriant. Personally, I'm fine > saying that those cases w

Re: [HACKERS] WIP: extensible enums

On Sat, Oct 23, 2010 at 10:11 PM, Robert Haas wrote: > I dunno if floats have completely > consistent representations on all the platforms we support, but with > integers it should be quite easy to predict the exact point when > you're going to run out of space and what the contents of pg_enum > s

Re: [HACKERS] ask for review of MERGE

On Sat, Oct 23, 2010 at 4:03 PM, Josh Berkus wrote: > I think that such a lock would also be useful for improving the FK deadlock > issues we have. I don't see how. I think the problem you're referring to occurs when different plans update rows in different orders and the resulting locks on forei