Hi Tom,
Did you manage to find a spare moment over the past week to check the
revised ANALYZE patch I posted to the list? Is there any more work that
needs to be done to it before it can applied to CVS?
TIA,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8B
Hi Tom,
Having been working with the PostGIS team to implement a custom analyze
routine for R-Tree selectivity, we have a question regarding the new
vacuum_delay_point() which is present in analyze.c. Is it the
responsibility of the programmers to remember to do a
vacuum_delay_point() before calli
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 13 February 2004 14:41
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
>
> "Mark Cave-Ayland&q
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> The only reason I kept the Relation parameter
> was because I wasn't sure if there was a historical reason why someone
> would need the relation information as well as the attribute
> information.
I can't think of one, but if someone did, they could
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 12 February 2004 23:52
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
>
> "Mark Cave-Ayland" <[EMAIL PROTECT
ark Cave-Ayland
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [PATCHES] ANALYZE patch for review
> >
> >
> > "Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> > > So I'd like to propose a slightly different solution. I think that
> > >
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> Yup indeed. Please find enclosed the latest version of the analyze patch
> taking into account all the things we have discussed in the thread.
I've reviewed and applied this with some small changes. You did a good
job --- the only things you missed
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> So I'd like to propose a slightly different solution. I think that
> examine_attribute() should return a pointer to a custom structure
> containing any information that needs to be passed to the datatype
> specific routine (not the entire VacAttrStat
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 29 January 2004 15:31
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
>
OK, I've had another attempt at writing the code
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> Is what you're saying that a custom function would do something like
> this:
> typedef struct
> {
> VacAttrStats *v;
> int mydata1;
> int mydata2;
> int mydata3;
> } mystruct;
> myanalyzeinfo = palloc0(sizeof(mys
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 27 January 2004 17:16
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
> > My thinking behind this was that examine_att
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
>> This would mean that pretty much the whole of
>> examine_attribute is treated as type-specific code. In
>> consequence there would be a certain amount of duplication of
>> code across different type-specific setup routines, but that
>> does not
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 25 January 2004 23:08
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
>
> "Mark Cave-Ayland" <[EMAIL PROTECTED]&g
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> Here is a first attempt at a patch to allow a customised ANALYZE
> function to be specified for user-defined types, relating to the
> following two threads:
> http://archives.postgresql.org/pgsql-hackers/2003-10/msg00113.php and
> http://archives.pos
14 matches
Mail list logo
