hi NikhilS.
2008/3/14, NikhilS [EMAIL PROTECTED]:
Hi Longlong,
i think this is a better idea.
from *NikhilS *
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php
But instead of using a per insert or a batch insert substraction, I am
thinking that we can start off a
lo_import_with_oid added.
Note that actually committed function signature is:
Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId);
--
Tatsuo Ishii
SRA OSS, Inc. Japan
It seems I forgot about the serer side lo_import. Included are the
patches to add new form of
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 named
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:
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
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 would have voted
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 is
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 contexts
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
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 TextPGetCString
and
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
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 C
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
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
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
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 the
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?
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 about
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 lock.
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
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
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
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
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
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 case
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 be
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
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
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
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-faster
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
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
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
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 check
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, as in
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
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 xids. That
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) order.
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 significant
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 ...
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
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
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).
Simon,
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
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
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 value in
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 just such a pain to
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 attempt
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-liner.
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
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't
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 recently
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 version
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; mostly, ensuring that
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 require.
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\nbar,
which is
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 that entry point
57 matches
Mail list logo
