On Mon, Sep 22, 2008 at 7:57 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> 50,000,000 rows and 32,768,000 collisions
I should mention thats 50 million rows + 32 million more or 62,768,000
rows which explains some of the added index creation time...
> index time:
> head: 576
On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> BTW, one thing I noticed was that the hash index build time for the
> "wide column" case got a lot worse after applying the patch (from 56 to
> 237 sec). The reason for this turned out to be that with the smaller
> predicted in
On Fri, Sep 12, 2008 at 8:29 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2008 at 08:51:53PM -0600, Alex Hunsaker wrote:
>> On Thu, Sep 11, 2008 at 9:24 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
>> > Alex,
>> >
>> >
On Fri, Sep 12, 2008 at 3:14 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker napsal(a):
>>
>> On Wed, Sep 10, 2008 at 10:27 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
>>>
>>> On Wed, Sep 10, 2008 at 8:47 AM, Zdenek Kotala <[EMAIL PROT
On Thu, Sep 11, 2008 at 9:24 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> Alex,
>
> I meant to check the performance with increasing numbers of collisions,
> not increasing size of the hashed item. In other words, something like
> this:
>
> for ($coll=500; $i<=100; $i=$i*2) {
> for ($i=0;
On Wed, Sep 10, 2008 at 9:49 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 7:04 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 09, 2008 at 07:23:03PM -0600, Alex Hunsaker wrote:
>>> On Tue, Sep 9, 2008 at 7:48 AM, Kenneth Mars
On Wed, Sep 10, 2008 at 7:04 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 09, 2008 at 07:23:03PM -0600, Alex Hunsaker wrote:
>> On Tue, Sep 9, 2008 at 7:48 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
>> > I think that the glacial speed for
On Wed, Sep 10, 2008 at 10:27 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 8:47 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>> What locale did you use? It would be nice to have also comparing between C
>> and any UTF8 locale. I think we should
On Wed, Sep 10, 2008 at 8:47 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> What locale did you use? It would be nice to have also comparing between C
> and any UTF8 locale. I think we should see big benefit when non C locale is
> used.
Err yes this was UTF8, Ill see about doing a C locale.
--
S
On Tue, Sep 9, 2008 at 7:23 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> BTW Im still planning on doing a wide vs narrow test... sometime... :)
narrow: (exactly the same as what I just did in the other post)
create table test_hash(num int8);
insert into test_hash (num) select generate
On Tue, Sep 9, 2008 at 7:23 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> create table test_hash(num int8);
> insert into test_hash (num) select generate_series(1, 200);
> create index test_hash_num_idx on test_hash (num);
>
> pgbench -c1 -n -t1 -f bench_inde
On Tue, Sep 9, 2008 at 7:48 AM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> I think that the glacial speed for generating a big hash index is
> the same problem that the original code faced.
Yeah sorry, I was not saying it was a new problem with the patch. Err
at least not trying to :) *Both* o
2008/9/6 Alex Hunsaker <[EMAIL PROTECTED]>:
> pgbench -c1 -n -t1000 -f bench_bitmap.sql
> cvs head: tps = 24.011871
> v5: tps = 2.543123
oops forgot to attach bench_bitmap.sql
bench_bitmap.sql
Description: Binary data
--
Sent via pgsql-patches mailing list
On Sat, Sep 6, 2008 at 1:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>For the convenience of anyone intending to test, here is an updated
>patch against CVS HEAD that incorporates Alex's fix.
Here are the results for a table containing 1 million entries that
will generate hash collisions. It paint
On Fri, Aug 29, 2008 at 7:39 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Well, it's been a long time coming, but I've finally got a patch to
> improve the error handling of to_date() and to_timestamp(), as
> previously discussed on -hackers. [1][2]
BTW -patches is obsolete just submi
]
On Fri, Sep 5, 2008 at 2:21 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> Ok now that I made it so it actually *test* collisions, with the patch
> it always returns all rows that matched the hashed "key".
And here is the fix, we just forget to set the recheck flag for bi
Ok now that I made it so it actually *test* collisions, with the patch
it always returns all rows that matched the hashed "key". For example
(non lobotomized inthash8, I just brute forced some collisions for 0
so that anyone can try this)
create table test_hash (num int8);
insert into test_hash (
On Thu, Sep 4, 2008 at 9:48 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> (obviously on a 64 bit machine)
> int main(void)
> {
>unsigned long y = 0;
>unsigned cnt = 0;
>
>printf("insert into test_hash (num) values ");
>
&
On Thu, Sep 4, 2008 at 9:48 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
Ok here are the results:
(data generated from the c program before)
select count(1) from test_hash;
count
---
10011
create index test_hash_num_idx on test_hash using hash (num);
CVS: Time: 698065.
On Thu, Sep 4, 2008 at 8:17 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I guess one thing we could do for testing purposes is lobotomize one of
> the datatype-specific hash functions. For instance, make int8_hash
> return the input mod 2^32, ignoring the upper bytes. Then it'd be easy
> to compute
On Thu, Sep 4, 2008 at 7:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So what we need for testing is a few different key values that hash to
> the same code. Not sure about an easy way to find such.
Hrm, well I have not really looked at the hash algorithm but I assume
we could just reduce the num
On Thu, Sep 4, 2008 at 7:13 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Ok let me know if this is to naive of an approach or not hitting the
>> right cases you want tested.
>
> You have the unique-versus-
On Thu, Sep 4, 2008 at 5:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So my thinking right now is that we should just test this patch as-is.
> If it doesn't show really horrid performance when there are lots of
> hash key collisions, we should forget the store-both-things idea and
> just go with th
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I would like to get do this without adding a new --use-statement-timeout
> flag. Is anyone going to want to honor statement_timeout during
> pg_dump/pg_restore? I thought we were just going to disable it.
I believe so.
On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So that's leading me to lean towards keeping RemoveRelation
> et al where they are and distributing the work currently done in
> ProcessUtility out to them. This sounds duplicative, but about all that
> really is there to dupli
On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Yep, I thought about doing the reverse. Namely Just passing the
>> DropStmt to RemoveRelation(s). But then all the permission check
>
On Thu, Jun 12, 2008 at 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I don't really like the patch though; it seems kind of a brute force
> solution. You've got ProcessUtility iterating through a list of objects
> and doing a little bit of work on each one, and then making a new list
> that Rem
On Thu, Jun 12, 2008 at 11:35 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I don't think there's anything wrong with that in principle. However,
> does your patch actually work? The changes in expected/ is unexpected,
> I think.
Yeah I thought they looked a bit odd at first to. I thought it w
On Wed, Jun 11, 2008 at 4:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Agreed --- I committed what I had, anyone want to volunteer for
> refactoring the execution of DropStmt?
Sure! see the attached patch...
> After looking again, I think that this is not technically very
> difficult, but coming
Tom Lane" <[EMAIL PROTECTED]> writes:
> I am wondering if it's a good idea to hide the redundant entries
> to reduce clutter in the pg_settings display. (We could do this
> by adding a "hidden" boolean to struct config_enum_entry.)
> Thoughts?
The Attached patch does just that...
guc_config_enu
On Fri, May 9, 2008 at 5:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> [ patch to change inherited-check-constraint behavior ]
>
> Applied after rather heavy editorializations. You didn't do very well on
&g
On Wed, May 7, 2008 at 12:20 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> Find attached a diff from v4-v5, and a full patch.
>
> src/backend/commands/tablecmds.c | 242
> +++-
>
> src/backend/utils/cache/syscache.c | 12 --
On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Joshua D. Drake escribió:
>
> > That is an interesting idea. Something like:
> >
> > pg_restore -E "SET STATEMENT_TIMEOUT=0; SET MAINTENANCE_WORK_MEM=1G" ?
>
> We already have it -- it's called PGOPTIONS.
>
Ok but is n
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
> I was taking a look at this patch to add the pg_dump related changes. Just
> wanted to give you a heads up as this patch crashes if we run "make
> installcheck". Seems there is an issue introduced in the CREATE TABLE
> It seems much more restrictive than necessary, plus it does nothing
> for the check-constraint case. My recollection of the previous
> discussion about how to fix this was that we needed to add an inhcount
> column to pg_constraint, and add entries for not-null constraints (at
> least inh
On Wed, Feb 20, 2008 at 3:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > create table junk (val integer not null, val2 integer);
> > create table junk_child () inherits (junk_1);
> > alter table junk_child
36 matches
Mail list logo
