On Mar 13, 2008, at 5:14 PM, James Mansion wrote:
James Mansion wrote:
In usage:
AFTER START clears counters and flags.
UPDATE triggers on data set counters and flags.
BEFORE COMMIT examines the counters and flags and performs any
final validation or
adjustments (or external events such as
"Decibel!" <[EMAIL PROTECTED]> writes:
If we're going to make this a ./configure option, ISTM we should
do the same
with XID size as well. I know there are high-velocity databases
that could use
that.
Keep in mind we just changed things so that read-only transactions
don't
consume xid
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > We can't just build the output table by hand like
> > describeOneTableDetails does? Admittedly it's kludgy, but it's not an
> > unprecedented kludge.
>
> Oh, I had forgotten the existence of tha
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The code is now set up so that it can pass an entire field value
>> through gettext(), but if gettext recognizes the strings "foo" and
>> "bar" that doesn't mean it will do anything useful with "foo\n
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The code is now set up so that it can pass an entire field value
> through gettext(), but if gettext recognizes the strings "foo" and
> "bar" that doesn't mean it will do anything useful with "foo\nbar",
> which is what this patch would req
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > As discussed on -hackers, this patch allows the construction of an
> > empty array if an explicit cast to an array type is given (as in,
> > ARRAY[]::int[]).
>
>
> Applied with minor fixes; mostl
On Thu, Mar 20, 2008 at 5:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Warren Turkal <[EMAIL PROTECTED]> writes:
>
> > Here's an initial bit of my attempt at cleaning up the the timestamp
> > datatype.
>
> I'm starting to work through this now. Your two messages of 3/09 are
> still the latest v
"Warren Turkal" <[EMAIL PROTECTED]> writes:
> I have to say, I am wondering more and more how real the need is for
> the two representations of timestamps. Would it be better to deprecate
> the float format or at least make the int64 format the default?
This was gone over in great detail just rece
Warren Turkal <[EMAIL PROTECTED]> writes:
> I added TimeOffset and DateOffset typedefs to get rid of the instances
> using the HAVE_INT64_TIMESTAMP define being used to determine the
> types of variables or functions in timestamp.c.
Applied with minor revisions. I dropped DateOffset since it didn
Warren Turkal <[EMAIL PROTECTED]> writes:
> Here's an initial bit of my attempt at cleaning up the the timestamp datatype.
I'm starting to work through this now. Your two messages of 3/09 are
still the latest version correct?
> 2) Would it be reasonable to change timestamp.h into a file that
> i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> Sure -- I sent in a patch earlier, but I'll post an updated version
>> shortly.
> Hmm, I mean just switching the default value in configure.in ... is
> there anything else that needs doing at this point?
Well, that's hardly a one-
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> gettext localizes the NULL string to the localization header :-( For
> example:
Oooh, that's even different from the one I thought of :-(. Yeah,
we've got a problem here.
We could fix that particular issue by changing print.c so that it
doesn't attem
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> If there are not additional votes, I'll go with TextPGetCString
>>> and CStringGetTextP.
>>
>> I would have voted for text_to_cstring etc. I can see the logic for the above
>> but it's j
Neil Conway wrote:
> On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
> > Neil, you're on the loop for changing the default in configure. Want to
> > do the honors?
>
> Sure -- I sent in a patch earlier, but I'll post an updated version
> shortly.
Hmm, I mean just switching the default v
Brendan Jurd escribió:
> I've done up a patch per Tom's idea of combining the binary role
> attributes into a single column.
Thanks -- this is nice. I even went to apply it, but found a problem:
gettext localizes the NULL string to the localization header :-( For
example:
alvherre=# \du
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I've done up a patch per Tom's idea of combining the binary role
> attributes into a single column.
I started to look at committing this and realized that there's a very
nasty problem: our current approach to localizing the strings won't
work. See this
On Thu, 2008-03-20 at 18:08 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Currently, our sort algorithm assumes that its input is unsorted. So if
> > your data is sorted on (a) and you would like it to be sorted on (a,b)
> > then we need to perform the full sort of (a,b).
>
On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
> Neil, you're on the loop for changing the default in configure. Want to
> do the honors?
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
-Neil
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Neil Conway wrote:
> Therefore, I propose that we make integer datetimes the default (perhaps
> for 8.4), and then eventually remove the floating-point datetime code.
Neil, you're on the loop for changing the default in configure. Want to
do the honors?
--
Alvaro Herrera
Gregory Stark <[EMAIL PROTECTED]> writes:
> All that said I don't really see much reason not to make it an option. I just
> don't think anyone really needs it. In 5-10 years though...
The manpower we'd have to invest in making it work and keeping it
working would be enough reason ...
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I did some tests with gcc 4.3 on the branches from 7.4 to 8.3 and head.
> 8.3 and head don't have a problem. All others failed in the
> ContribCheck state.
> You can see the results on buildfarm member panda.
Bizarre. There doesn't seem to be any signif
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If we assume we use heap sort, then if we *know* that the data is
> presorted on (a) then we should be able to emit tuples directly that the
> value of (a) changes and keep emitting them until the heap is empty,
> since they will exit the heap in (a,b) o
"Decibel!" <[EMAIL PROTECTED]> writes:
> If we're going to make this a ./configure option, ISTM we should do the same
> with XID size as well. I know there are high-velocity databases that could
> use
> that.
Keep in mind we just changed things so that read-only transactions don't
consume xid
Simon Riggs <[EMAIL PROTECTED]> writes:
> Currently, our sort algorithm assumes that its input is unsorted. So if
> your data is sorted on (a) and you would like it to be sorted on (a,b)
> then we need to perform the full sort of (a,b).
Simon, would it be too much to ask that you concentrate on re
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> As discussed on -hackers, this patch allows the construction of an
> empty array if an explicit cast to an array type is given (as in,
> ARRAY[]::int[]).
Applied with minor fixes; mostly, ensuring that the cast action would
propagate down to sub-arrays,
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If the uniqueness check used a scan key that consisted of all of the
> Primary Key columns, rather than just the index columns then it would be
> able to scan through non-unique index entries to check uniqueness.
> Interestingly, the current uniqueness c
On Thu, Mar 20, 2008 at 05:17:22PM +, Simon Riggs wrote:
> Currently, our sort algorithm assumes that its input is unsorted. So if
> your data is sorted on (a) and you would like it to be sorted on (a,b)
> then we need to perform the full sort of (a,b).
>
> For small sorts this doesn't matter
Heikki Linnakangas wrote:
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
I also wonder what the performance impact of extending BufferTag is.
That's a fair objection, and obviously something we'd need to check.
But I don't recall seeing hash_any so high on any profile that I
Hi,
I did some tests with gcc 4.3 on the branches from 7.4 to 8.3 and head.
8.3 and head don't have a problem. All others failed in the
ContribCheck state.
You can see the results on buildfarm member panda.
Kurt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> More precisely, on CVS HEAD it takes between 7.1-7.2%. After extending
> BufferTag with one uint32, it takes 7.4-7.5%. So the effect is
> measurable if you try hard enough, but not anything to get worried about.
And if we adopt the allegedly-fas
On Thu, 2008-03-20 at 17:38 +, Gregory Stark wrote:
> I don't immediately see any problems aside from reduced concurrency
Agreed. The index would need to be nearly unique in most cases to make
it sensible. But that's a common situation in complex data models.
--
Simon Riggs
2ndQuadrant
On Thu, 2008-03-20 at 18:37 +0100, Martijn van Oosterhout wrote:
> On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> > This would then allow us to use a Hash Index or other index as the basis
> > for a Unique Constraint and/or considerably reduce size of indexes.
>
> I was under the i
On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> The current Unique constraint relies directly upon a Unique index to
> test for uniqueness.
>
> This has two disadvantages:
>
> * only B-Trees currently support Uniqueness
> * We need to create an index on *all* of the columns of the
This would be very useful for me, and would satisfy the OP's request.
Can we get a TODO?
On Mar 9, 2008, at 4:45 PM, Dawid Kuroczko wrote:
On Sun, Mar 9, 2008 at 7:25 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
"=?ISO-8859-2?Q?Micha=B3_Zaborowski?="
<[EMAIL PROTECTED]> writes:
I would like to
On Thu, Mar 20, 2008 at 11:17:10AM -0500, Decibel! wrote:
> On Mar 10, 2008, at 1:26 PM, Peter Eisentraut wrote:
>
> At some point I think it makes a lot more sense to just have VACUUM gather
> stats as it goes, rather than have ANALYZE generate a bunch of random IO.
>
> BTW, when it comes to the
Currently, our sort algorithm assumes that its input is unsorted. So if
your data is sorted on (a) and you would like it to be sorted on (a,b)
then we need to perform the full sort of (a,b).
For small sorts this doesn't matter much. For larger sorts the heap sort
algorithm will typically result in
Hi,
I'm trying to write a version of the MIN aggregate for values of RECORD
type. I'm somewhat stuck on getting type information about the argument
out, I can determine how many attributes it's got but I can't seem to do
any better than that. Does anyone have any good pointers into the code
for
On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> This would then allow us to use a Hash Index or other index as the basis
> for a Unique Constraint and/or considerably reduce size of indexes.
I was under the impression that the reason only b-tree supported unique
indexes was because
On Mar 10, 2008, at 12:06 PM, Heikki Linnakangas wrote:
Gregory Stark wrote:
I don't understand. The patch only affects configuration and SQL
data type
code. It doesn't actually store the 64-bit commandid anywhere
which would be
the actual hard part.
Sure it does, this is the significant p
On Sun, February 10, 2008 18:35, Gurjeet Singh wrote:
> libpqxx seems to have moved around quite a bit. The attached patch
> corrects
> libpqxx's homepage.
Thanks for that. However just http://pqxx.org/ would be best. I'm just
setting up new hosting, and I may not get everything completely
link-
On Thu, Mar 20, 2008 at 4:56 PM, Decibel! <[EMAIL PROTECTED]> wrote:
> This would be very useful for me, and would satisfy the OP's request.
>
> Can we get a TODO?
If you feel adventureous you may UPDATE catalog constrains directly,
which will work more or less as "enforce, don't validate, don't
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> A quick recap: I submitted a patch for empty ARRAY[] syntax back in
> November, and as far as I can see it never made it to the patches
> list. Gregory suggested a different way of approaching the problem
> (quoted below), but nobody commented further a
On Mar 10, 2008, at 1:26 PM, Peter Eisentraut wrote:
Am Montag, 10. März 2008 schrieb Gregory Stark:
It's not possible to believe that you'd not notice O(N^2)
behavior for N
approaching 80 ;-). Perhaps your join columns were unique
keys, and
thus didn't have any most-common-values?
We
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Breaking the type_sanity test is not acceptable. Put in a second C
>> function.
> Are you talking opr_sanity?
Sorry, yes, too little caffeine ...
> What is evil with a polymorphic function?
(1) It's creating a false match --- your proposed entry in t
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Wed, Mar 19, 2008 at 07:55:40PM -0400, Tom Lane wrote:
>> (that's \303\240 or 0xc3 0xa0). I am thinking that something decided
>> the \240 was junk and removed it.
> Hmm, it is coincidently the space character +0x80, which is defined as
> a
The current Unique constraint relies directly upon a Unique index to
test for uniqueness.
This has two disadvantages:
* only B-Trees currently support Uniqueness
* We need to create an index on *all* of the columns of the primary key,
which may end up being a very large index as a result
The un
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > It seems I forgot about the serer side lo_import. Included are the
> > patches to add new form of lo_import which accepts the large object id
> > as the second argument.
>
> > Comments, objection?
>
> Breaking the type_sanity test is not acceptable.
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It seems I forgot about the serer side lo_import. Included are the
> patches to add new form of lo_import which accepts the large object id
> as the second argument.
> Comments, objection?
Breaking the type_sanity test is not acceptable. Put in a second
On Wed, Mar 19, 2008 at 07:55:40PM -0400, Tom Lane wrote:
> (that's \303\240 or 0xc3 0xa0). I am thinking that something decided
> the \240 was junk and removed it.
Hmm, it is coincidently the space character +0x80, which is defined as
a non-breaking space in many Latin encodings. Perhaps ctype d
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Volkan YAZICI <[EMAIL PROTECTED]> writes:
> >> But I'd vote for TextPGetCString style Tom suggested for the eye-habit
> >> compatibility with the rest of the code.
> >
> > If there are not additional votes, I'll go with TextPGetCS
Everything seems to work fine, except on the final call it has no more
data to return so cleans up all it's internal data structures and
returns with SRF_RETURN_DONE(funcctx).
If you are doing your development work on a Linux host, you may find it
useful to run the postmaster through valgrind
src/backend/utils/mmgr/README contains more information about the same too.
Regards,
Nikhils
On Thu, Mar 20, 2008 at 2:41 PM, Pavan Deolasee <[EMAIL PROTECTED]>
wrote:
> On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <[EMAIL PROTECTED]> wrote:
>
> >
> > I had to fiddle about with switching memory
On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <[EMAIL PROTECTED]> wrote:
>
> I had to fiddle about with switching memory contexts rather a lot to
> make it work this far, but I'm only guessing as to when it's appropriate
> to call MemoryContextSwitchTo(), and to which context to switch to
Here
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
>> But I'd vote for TextPGetCString style Tom suggested for the eye-habit
>> compatibility with the rest of the code.
>
> If there are not additional votes, I'll go with TextPGetCString
> and CStringGetTextP.
I wou
Hi,
I've written a custom C-language function that takes a SQL select
statement as it's input parameter, runs the query using the SPI
interface, iterates over all the results of the select using a cursor
and collates the data using a tsearch type binary tree, then walks the
tree to create a f
Howdy,
> Did you post an updated patch to HEAD?
>
No, but I guess its just about time. Hopefully I'll have
something to show next week.
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Thu, Mar 20, 2008 at 3:24 AM, Stephen Denne
<[EMAIL PROTECTED]> wrote:
>
> Pavan also refers to deferred triggers, which has got me thinking about
> another possible solution:
>
> Instead of inserting a delta row, that will be updated a lot of times,
> create an on commit drop temp table na
57 matches
Mail list logo
