Howdy,
I've attached a new patch with the latest revisions of for the citext
contrib module patch. The changes include:
* Using strlen() to pass string lengths to the comparison function,
since lowercasing the value can change the length. Per Tom Lane.
* Made citextcmp consistently return i
On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote:
> > > No idea. What do you think if we allow only one query name at the
> > > moment.
> >
> > I'm not sure I understand what that has to do with sorting.
> >
> > Please find attached a place where I've found some problems sorting by
>
On Mon, 7 Jul 2008, ITAGAKI Takahiro wrote:
I will have a plan to test it on RAID-5 disks, where sequential writing
are much better than random writing. I'll send the result as an evidence.
If you're running more tests here, please turn on log_checkpoints and
collect the logs while the test i
> On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote:
> > > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > > > Here is the patches he made against CVS HEAD (as of today).
> > > >
> > > > According to him followings are fixed with the patches:
> > > >
> > > > - fix cru
On Jul 15, 2008, at 20:26, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
So I guess my question is: what is wrong with the properties for
citextsend/citextrecv
[ checks catalogs... ] textsend and textrecv are marked STABLE not
IMMUTABLE. I am not totally sure about the reas
attached are two patches:
1. documentation
2. regression tests
for headline with fragments.
-Sushant.
On Tue, 2008-07-15 at 13:29 +0400, Teodor Sigaev wrote:
> > Attached a new patch that:
> >
> > 1. fixes previous bug
> > 2. better handles the case when cover size is greater than the MaxWords
On Jul 15, 2008, at 4:58 PM, Tom Lane wrote:
There are two ways we
could do it: a bool column that is TRUE if the function is variadic,
or an oid column that is the variadic array's element type, or zero
if the function isn't variadic. The second would take more space but
would avoid having to d
Decibel! <[EMAIL PROTECTED]> writes:
> On Jul 15, 2008, at 4:58 PM, Tom Lane wrote:
>> There are two ways we
>> could do it: a bool column that is TRUE if the function is variadic,
>> or an oid column that is the variadic array's element type, or zero
>> if the function isn't variadic. The second
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> So I guess my question is: what is wrong with the properties for
> citextsend/citextrecv
[ checks catalogs... ] textsend and textrecv are marked STABLE not
IMMUTABLE. I am not totally sure about the reasoning offhand --- it
might be because thei
Tom Lane <[EMAIL PROTECTED]> wrote:
> >> That raises the question of whether we should have ExecutorStart() and
> >> ExecutorEnd() hooks as well, to round things off.
> > Yeah, and also ExecutorRewind() hook.
>
> I'm happy to put in hooks that there's a demonstrated need for,
Hmm, ok. I just wa
On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote:
> > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > > Here is the patches he made against CVS HEAD (as of today).
> > >
> > > According to him followings are fixed with the patches:
> > >
> > > - fix crush with DISTIN
Is this a TODO item?
---
Greg Smith wrote:
> On Tue, 3 Jun 2008, Tom Lane wrote:
>
> > Well, the stuff included into the dump by pg_dump -v is informative,
> > too. But we stopped doing that by default because of complaint
On Jul 15, 2008, at 12:56, Tom Lane wrote:
Don't run the tests in a read-only directory, perhaps.
Yes, I changed the owner to the postgres system user and that did the
trick.
Or do they matter for sanity-checking citext?
Hard to tell --- I'd suggest trying to get a clean run. As for
> On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > Here is the patches he made against CVS HEAD (as of today).
> >
> > According to him followings are fixed with the patches:
> >
> > - fix crush with DISTINCT
> > - fix creating VIEW
> > - fix the case when recursion plan has anot
Hi, hackers.
I'm working on my gsoc project of improving hash index.
I posted a thread to ask some questions about implementation a few hours ago.
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00721.php
Someone's advice reminds me of the problem of design decision again.
I store hash in
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/7/15 Tom Lane <[EMAIL PROTECTED]>:
>> Also, it occurs to me that we could buy back a good part of the extra
>> space if we allowed pg_proc.probin to be NULL for internal functions.
>> Right now it's always "-" in that case, which is useless ...
>
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Well now that was cool to see. I got some failures, of course, but
> nothing stands out to me as an obvious bug. I attach the diffs file
> (with the citext.sql failure removed) for your perusal. What would be
> the best way for me to resolve th
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > Added to TODO:
> > > >
> > > > o Reduce PITR WAL file size by removing full page writes and
> > > > by removing trailing bytes to improve compression
> > >
> > > If w
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Added to TODO:
> > >
> > > o Reduce PITR WAL file size by removing full page writes and
> > > by removing trailing bytes to improve compression
> >
> > If we remove full page writes, how does hint b
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Added to TODO:
> >
> > o Reduce PITR WAL file size by removing full page writes and
> > by removing trailing bytes to improve compression
>
> If we remove full page writes, how does hint bit setting get propagated
> to the slav
2008/7/15 Tom Lane <[EMAIL PROTECTED]>:
> The proposed variadic-functions patch inserts some none-too-cheap code
> into FuncnameGetCandidates (it's deconstructing the proargmodes column
> to see if the function is variadic or not) which gets executed whether
> or not there are any variadic function
Bruce Momjian wrote:
> Added to TODO:
>
> o Reduce PITR WAL file size by removing full page writes and
> by removing trailing bytes to improve compression
If we remove full page writes, how does hint bit setting get propagated
to the slave?
--
Alvaro Herrera
The proposed variadic-functions patch inserts some none-too-cheap code
into FuncnameGetCandidates (it's deconstructing the proargmodes column
to see if the function is variadic or not) which gets executed whether
or not there are any variadic functions involved. I checked whether
this would cause
Kless wrote:
I'm sorry, but it was necessary that certain answers were answered by
someone with wide knowledge on databases and overall about its own
database. This one was the only way, and I believe that it has been
enough positive, at least for the end users -every one that choose its
data b
I'm sorry, but it was necessary that certain answers were answered by
someone with wide knowledge on databases and overall about its own
database. This one was the only way, and I believe that it has been
enough positive, at least for the end users -every one that choose its
data base-. At least th
First - please stop copying this list - this is not the "convince Jerry
to include UUID in MySQL" mailing list.
Really - I don't care what he thinks. But, on the subjects themselves
and how they apply to *PostgreSQL*:
Non-standard features just force people to stick with that one
product.
Hi,
Alvaro Herrera wrote:
I think the
way to go here is to have Markus open up his Monotone repo, or convince
him to migrate it to Git, but I really doubt that's ever going to
happen.
He he... good guess ;-)
However, as much as I personally like monotone and as much as I dislike
git for being
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed. I realize why we are not zeroing those bytes (for performance),
> > but can't we have the archiver zero those bytes before calling the
> > 'archive_command'?
>
> The archiver doesn't know any more about where the end-of-data
On Jul 15, 2008, at 07:09, Tom Lane wrote:
Yeah, probably. I don't think the "make check" path will support it
because it doesn't install contrib into the temp installation.
(You'd also need to have put the extra entry in parallel_schedule
not serial_schedule, but it's not gonna work anyway.)
At 2008-07-15 08:34:01 -0700, [EMAIL PROTECTED] wrote:
>
> An answer of Jerry Stuckle:
Please stop cross-posting messages from this list to whatever MySQL list
you're on. It's a boring, pointless waste of time at best, and at worst
will get you written off as a troll in both places pretty soon.
-
An answer of Jerry Stuckle:
---
>> Yes, they must be managed by the language. Which is why it should be
>> part of the standard. That way, changing databases does not require
>> changing code.
> You are correct that putting widely used features into a standard that
> is impl
Hi,
After having published the source code, I'd like to add some words about
the current state of the project.
Postgres-R is currently capable of replicating tuples via binary change
sets, does proper conflict detection and prevention. It offers three
different timing methods: sync, eager an
At 2008-07-15 10:33:02 -0400, [EMAIL PROTECTED] wrote:
>
> I doubt we'd consider accepting a patch done this way.
Yes, it's much too ugly to live. I was posting it only for the record,
I should have made that clear.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>>> Also, after looking at the patch more closely, was there a good reason
>>> for making the hook intercept ExecutePlan rather than ExecutorRun?
>>
>> That raises the question of whether we should have ExecutorS
On Tue, Jul 15, 2008 at 5:56 AM, Xiao Meng <[EMAIL PROTECTED]> wrote:
> Hi, hackers.
> I'm working on my gsoc project - improving hash index.
Given the amount of time left for SoC, can you please post to -hackers
your proposed design for review and comments (under a new topic).
--
Jonah H. Harri
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> Refactoring pg_dump was more work than I had time to do right now, and I
> wanted \ef to work, so I hacked up the attached (by copying dumpFunc and
> its dependencies to src/bin/psql/dumpfunc.[ch]).
I doubt we'd consider accepting a patch done this w
On Tue, Jul 15, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> I would actually suggest ditching the normal page layout with line
>> pointers and IndexTuples altogether.
>
> It would be a bad idea to remove the page header. You need the
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I would actually suggest ditching the normal page layout with line
> pointers and IndexTuples altogether.
It would be a bad idea to remove the page header. You need the LSN
(someday hash indexes will obey WAL logging), and removing the page
vers
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Okay, I copied citext.sql into src/test/regress/sql and then added
> "test: citext" to the top of src/test/regress/serial_schedule. Then I
> ran `make check`. All tests passed, but I don't think that citext was
> tested.
> Do I need to install
Added to TODO:
* Consider decreasing the I/O caused by updating tuple hint bits
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php
---
Simon Riggs wrote:
> After some discussions at PGCon, I'd like to mak
Oh, I almost forget the problem of item size.
What I consider is just to modify the source code as few as possible;-(
Thank you for reminding me, Heikki.
I can see in the older version of postgresql, it remove a structure
HashItem and just use indextuple to store the item.
Now I would use a struct
Xiao Meng wrote:
Hi, hackers.
I'm working on my gsoc project - improving hash index.
I need to create a TupldeDesc with uint32 attribute.
Here is the reason why I need it -
If we store hash code only in the tuple, then the TupleDesc's
attribute should be uint32
Something along the lines of:
Tu
Refactoring pg_dump was more work than I had time to do right now, and I
wanted \ef to work, so I hacked up the attached (by copying dumpFunc and
its dependencies to src/bin/psql/dumpfunc.[ch]).
-- ams
*** a/src/bin/psql/Makefile
--- b/src/bin/psql/Makefile
***
*** 21,27 override
Hi, hackers.
I'm working on my gsoc project - improving hash index.
I need to create a TupldeDesc with uint32 attribute.
Here is the reason why I need it -
If we store hash code only in the tuple, then the TupleDesc's
attribute should be uint32.
In this way, we can use index_form_tuple() to create
Attached a new patch that:
1. fixes previous bug
2. better handles the case when cover size is greater than the MaxWords.
Looks good, I'll make some tests with real-world application.
I have not yet added the regression tests. The regression test suite
seemed to be only ensuring that the fu
On Tue, 2008-07-15 at 16:25 +0900, ITAGAKI Takahiro wrote:
> > > Also, after looking at the patch more closely, was there a good
> reason
> > > for making the hook intercept ExecutePlan rather than ExecutorRun?
> >
> > That raises the question of whether we should have ExecutorStart()
> and
> > E
Gregory Stark wrote:
I thought
we only pruned when we wanted to insert a new tuple and found not enough
space.
Nope, we prune on any access to the page, if the page is "full enough",
and the pd_prune_xid field suggests that there is something to prune.
The problem with only pruning on insert
Simon Riggs <[EMAIL PROTECTED]> wrote:
> > I wonder whether we ought to change things so that the real query
> > source text is available at the executor level. Since we are (at least
> > usually) storing the query text in cached plans, I think this might just
> > require some API refactoring, n
48 matches
Mail list logo
