Hi Marc,
>
> > I think I'm telling you what you already know, but there are lots
> of names
> > missing from that list (myself included), so that process isn't
> going to
> > work.
>
Me too. Maybe some improvement in the routine.
> When you submit'd your patch, where did you submit this to?
Tom Lane wrote:
> Bruce Momjian writes:
> > As you can see it is the confusion that bothers me. I am not sure how I
> > would write a coherent paragraph explaining this.
>
> The same thing you wrote the last time we had to do this (7.3.1).
> I don't recall any huge volume of complaints last time
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > We can't build the files very easily during WAL recovery, but
> > what about if we compare the files to the database after the normal
> > backend startup? If they're different, regenerate the files.
>
> This ass
Just brain storming a bit here. It seems to me there are two approaches for
cross-column statistics within a single table:
A) Treat an index on the same way Postgres treats an expression index
on ROW(a,b,c). That is, gather full statistics on the distribution of that
ntuple of columns. I
* Tom Lane ([EMAIL PROTECTED]) wrote:
> What I am thinking is that we have to punt on this problem until the
> proposed pg_role catalog is in place. With the grolist array
> representation of group membership replaced by a fixed-width
> pg_role_members catalog, there would be no need to deal with
Stephen Frost <[EMAIL PROTECTED]> writes:
> We can't build the files very easily during WAL recovery, but
> what about if we compare the files to the database after the normal
> backend startup? If they're different, regenerate the files.
This assumes that you can get in in the first place, which
Marc G. Fournier wrote:
On Sat, 5 Feb 2005, Matthew T. O'Connor wrote:
Well I'm positive I submitted all my pg_autovacuum patches to the
patches list, however searching the archives for autovacuum I can't
find anything that old. How far back to the searchable archives go?
back to 96 or so ... :
On Sat, 5 Feb 2005, Matthew T. O'Connor wrote:
Marc G. Fournier wrote:
On Sat, 5 Feb 2005, Matthew T. O'Connor wrote:
I think I'm telling you what you already know, but there are lots of names
missing from that list (myself included), so that process isn't going to
work.
When you submit'd your p
Marc G. Fournier wrote:
On Sat, 5 Feb 2005, Matthew T. O'Connor wrote:
I think I'm telling you what you already know, but there are lots of
names missing from that list (myself included), so that process isn't
going to work.
When you submit'd your patch, where did you submit this to? As I
said
On Sat, 5 Feb 2005, Matthew T. O'Connor wrote:
I think I'm telling you what you already know, but there are lots of names
missing from that list (myself included), so that process isn't going to
work.
When you submit'd your patch, where did you submit this to? As I said,
this list is of all tho
I think I'm telling you what you already know, but there are lots of
names missing from that list (myself included), so that process isn't
going to work.
Matthew
Marc G. Fournier wrote:
Using the same search for 7.4 shows only 48 patch submitters, based on
posts to pgsql-patches ...
Aizaz Ahme
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Feb 04, 2005 at 03:16:33PM -0500, Tom Lane wrote:
>> Michael Klatt reported here:
>> http://archives.postgresql.org/pgsql-admin/2005-02/msg00031.php
>> that we have problems because the flat files global/pg_pwd
>> and global/pg_group aren't rebui
Title: RE: [HACKERS] Escaping the ARC patent
>
> Just an idle thought, but each connection to the DB could add a fixed
> amount to some queueing parameter. The amount added to be set
> per backend,
> and the client could use a SET variable to adjust the
> standard amount for
> it's own b
Bruce Momjian writes:
> As you can see it is the confusion that bothers me. I am not sure how I
> would write a coherent paragraph explaining this.
The same thing you wrote the last time we had to do this (7.3.1).
I don't recall any huge volume of complaints last time, so I think
you're making a
> [EMAIL PROTECTED] writes:
>>-> Index Scan using rt1_zipr, rt1_zipl on rt1 (cost=0.00..121893.93
>> rows=30835 width=302)
>> Index Cond: ((zipr = 2186) OR (zipl = 2186))
>
>> zipl |925 |
>> zipr |899 |
>
> Those n_distinct values for zipl and zipr seem ab
15 matches
Mail list logo
