Replying to myself, but I've made some local changes (see other
messages) and just wanted to follow up on some of my own comments.
On Jul 2, 2008, at 21:38, David E. Wheeler wrote:
4) Operator = citext_eq is not correct. See comment
http://doxygen.postgresql.org/varlena_8c.html#8621d064d14f
On Jul 2, 2008, at 22:14, Tom Lane wrote:
The "leak" is irrelevant for larger/smaller. The only place where
it's
actually useful to do PG_FREE_IF_COPY is in a btree or hash index
support function. In other cases you can assume that you're being
called in a memory context that's too short-liv
On Jul 3, 2008, at 09:53, Alvaro Herrera wrote:
Thanks. What would citext_hash() look like? I don't see a
text_hash() to
borrow from anywhere in src/.
See hash_any(). I assume the difficulty is making sure that
hash("FOO") = hash("foo") ...
Great, big help, thank you. So does this look se
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The data structure I'd suggest is a simple array of pointers
to the underlying hash table entries. Since you have a predetermined
maximum number of lexemes to track, you can just palloc the array once
--- you don'
Magnus Hagander wrote:
> Tom Lane wrote:
> > According to what you just told me, the original coding is storing the
> > name in a "local namespace", which presumably means it won't conflict
> > anyway. Ergo, the existing coding is simply broken and there's nothing
> > we can do about it.
>
> Loc
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas wrote:
>>> What happens if someone launches version 8.3.3 postgres.exe and version
>>> 8.3.4 postgres.exe at the same time, on the same data directory? Will
>>> the interlock that prevents two postmasters from start
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
I see no value in cluttering the system with useless probes. The worker
start/stop are the only ones here with any conceivable application IMHO.
As I answered to Alvaro. I needed to catch start of backend several times
to tr
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
proc-master-start
proc-master-stop
What's "master" here?
Main process - postmaster.
Huh, surely we're not interested in tracking postmaster start?
It depends. See following schema example
postgres::proc-master-s
Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> I see no value in cluttering the system with useless probes. The worker
>> start/stop are the only ones here with any conceivable application IMHO.
>
> As I answered to Alvaro. I needed to catch start of backend several times
> to track call flow or
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>>> proc-master-start
>>> proc-master-stop
>>
>> What's "master" here?
>
> Main process - postmaster.
Huh, surely we're not interested in tracking postmaster start?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Th
Tom Lane napsal(a):
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Autovacuum_start probe is alone. I propose following probes for completeness:
proc-autovacuum-start
proc-autovacuum-stop
proc-bgwriter-start
proc-bgwriter-stop
Separate proc-autovacuum-worker-start and proc-autovacuum-launcher-st
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
1) Naming convention:
- Some probes uses "*end", some "*done". It would be good to select one name.
- I prefer to use clog instead of slru in probes name. clog is widely known.
But slru is also used in pg_subtrans and pg_multixact. Which mayb
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Autovacuum_start probe is alone. I propose following probes for completeness:
>>
>> proc-autovacuum-start
>> proc-autovacuum-stop
>> proc-bgwriter-start
>> proc-bgwriter-stop
> Separate proc-autovacuum-worker-start and proc-autovacuum-launcher-start,
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> What happens if someone launches version 8.3.3 postgres.exe and version
>> 8.3.4 postgres.exe at the same time, on the same data directory? Will
>> the interlock that prevents two postmasters from starting at the same
>> tim
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 4. Juli 2008 schrieb Tom Raney:
>> Regarding the XML datum, in order to support that, will all users need
>> to compile with libxml? Are there any lighter weight solutions to
>> serialize other than libxml?
> You can create XML withou
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The data structure I'd suggest is a simple array of pointers
>> to the underlying hash table entries. Since you have a predetermined
>> maximum number of lexemes to track, you can just palloc the array once
>> --- you don't need
Zdenek Kotala wrote:
> 1) Naming convention:
>
> - Some probes uses "*end", some "*done". It would be good to select one name.
> - I prefer to use clog instead of slru in probes name. clog is widely known.
But slru is also used in pg_subtrans and pg_multixact. Which maybe
says that we oughta h
I performed review of merged patch from Robert Treat. At first point the patch
does not work (SunOS 5.11 snv_86 sun4u sparc SUNW,Sun-Fire-V240)
truncate ... ok
alter_table ... FAILED (test process exited with exit code 2)
sequence ... ok
polym
--On Freitag, Juli 04, 2008 11:31:07 +0200 Stefan Kaltenbrunner
<[EMAIL PROTECTED]> wrote:
I just noticed that setting log_rotation_age to a value larger than 24
days results in rather weird output (I have not actually tested yet if
that affects the functionality too or just the output):
test
Volkan YAZICI napsal(a):
Hi,
pg_dump is capable of dumping objects with respect to their dependency
relations. It'd be really awesome if pg_dump can also handle
parallelizing primary key, foreign key and index creation queries into
separate files. Would such a think be possible? Comments?
[EMAIL PROTECTED] ("Ken Camann") writes:
> On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Ken Camann" <[EMAIL PROTECTED]> writes:
>>> EMT64/AMD64 is new compared to the older architectures, I
>>> would guess the older ones predate the time when it became a somewhat
>>> de
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> below this is going to convert \ to /, wouldn't it be clearer to
>>> describe the path prefix as Global/PostgreSQL: in the first place?
>
>> Eh, that shows another bug I think. It should *not* convert the \ in
>> "Global\", because
On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
> --On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
>
> >>
> >> I'd like to implement them if we agree on them
> >
> > Bernd, have you made any progress on this?
>
> Here's a patch for this. I'll add it to
I just noticed that setting log_rotation_age to a value larger than 24
days results in rather weird output (I have not actually tested yet if
that affects the functionality too or just the output):
test=# show log_rotation_age;
log_rotation_age
--
-2134967296ms
(1 row)
this
On Fri, 4 Jul 2008, Teodor Sigaev wrote:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb
Am Freitag, 4. Juli 2008 schrieb Tom Raney:
> Regarding the XML datum, in order to support that, will all users need
> to compile with libxml? Are there any lighter weight solutions to
> serialize other than libxml?
You can create XML without libxml.
--
Sent via pgsql-hackers mailing list (
On Thu, Jul 03, 2008 at 01:45:06AM -0400, Ken Camann wrote:
> When 32-bit arrived (much too late, at Microsoft) most x86 compilers
> that had formerly used the segmented memory model made int 4 bytes
> like people felt "it was supposed to be" but left long at 4 the way it
> was so as not to bloat a
> What's the benefit of a multi-column GIN index over multiple
> single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb538 Mb
Speed: *1.885* ms4.9
Dumb question:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Have you looked into the machine's kernel log to see if there is any
> evidence of low-level distress (hardware or filesystem level)? I'm
> wondering if ENOSPC is being reported because it is the closest
> available errno code, but the real problem is some
Tom Lane wrote:
The data structure I'd suggest is a simple array of pointers
to the underlying hash table entries. Since you have a predetermined
maximum number of lexemes to track, you can just palloc the array once
--- you don't need the expansibility properties of a list.
The number of lex
Quoting daveg <[EMAIL PROTECTED]>:
On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote:
On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote:
> It would also be interesting if EXPLAIN could optionally be a
> function that returns a datum of type XML, to allow further
> proc
32 matches
Mail list logo
