| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Ron Peacetree <rjpeace(at)earthlink(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] A Better External Sort? |
| Date: | 2005-10-02 03:26:07 |
| Message-ID: | 29837.1128223567@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Anyway, to bring some real info I just profiled PostgreSQL 8.1beta
> doing an index create on a 2960296 row table (3 columns, table size
> 317MB).
3 columns in the index you mean? What were the column datatypes?
Any null values?
> The number 1 bottleneck with 41% of user time is comparetup_index.
> ...
> The thing is, I can't see anything in comparetup_index() that could
> take much time.
The index_getattr and heap_getattr macros can be annoyingly expensive.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-10-02 05:24:07 | Re: effective SELECT from child tables |
| Previous Message | Martijn van Oosterhout | 2005-10-01 21:56:07 | Re: [PERFORM] A Better External Sort? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2005-10-02 12:32:45 | Re: [PERFORM] A Better External Sort? |
| Previous Message | Martijn van Oosterhout | 2005-10-01 21:56:07 | Re: [PERFORM] A Better External Sort? |