| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: inline newNode() |
| Date: | 2002-10-08 22:59:44 |
| Message-ID: | 873crgpme7.fsf@mailbox.samurai.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Or make a version of palloc that zeroes the memory.
Well, we might lose a bit of speed that way -- with the current
MemSet() macro, most of the tests that MemSet() does can be eliminated
at compile-time, since MemSet() is usually called with some constant
parameters. If we moved this code inside palloc(), it wouldn't be
possible to do this constant propagation.
Not sure it would make a big performance difference, though -- and I
think palloc() is a clean solution. In fact, it's probably worth
having anyway: a lot of the call sites of palloc() immediately zero
the memory after they allocate it...
Cheers,
Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurette Cisneros | 2002-10-08 23:34:02 | pgsql 7.2.3 crash |
| Previous Message | Martijn van Oosterhout | 2002-10-08 22:51:11 | Re: [HACKERS] Large databases, performance |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-10-09 00:07:30 | Re: inline newNode() |
| Previous Message | Kris Jurka | 2002-10-08 22:34:52 | Re: Bug #794: JDBC 7.3 PreparedStatement.setNull(..) |