On Fri, Apr 22, 2005 at 11:46:04AM -0300, Marc G. Fournier wrote:
> Actually, what I'm more "worried" about is the optimizations added to 4.x
> ... I know, for instance, that with FreeBSD's kernel, for the longest time
> you couldn't use the higher optimizations in 3.x, since it would cause
> "
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 9:46 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> With GCC 4.x, there are new optimi
See this TODO:
* Allow data to be pulled directly from indexes
Currently indexes do not have enough tuple visibility information
to allow data to be pulled from the index without also accessing
the heap. One way to allow this is to set a bit
Joshua D. Drake wrote:
Simply put, MD5 is no longer strong enough for protecting secrets. It's
just too easy to brute-force. SHA1 is ok for now, but it's days are
numbered as well. I think it would be good to alter SHA1 (or something
stronger) as an alternative to MD5, and I see no reason not to us
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Dave Held
> Sent: Friday, April 22, 2005 10:23 AM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> > -Origina
Fetching data from just indexes has been discussed on this list several
times before, and it has been told that this can't be done with postgres
thanks to MVCC.
But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying o
On Thu, 2005-04-21 at 17:27 -0500, Bruno Wolff III wrote:
> On Wed, Apr 20, 2005 at 22:27:01 -0400,
> Stephen Frost <[EMAIL PROTECTED]> wrote:
> >
> > SHA2 would also be nice.
>
> I think the new hash functions are called SHA256 and SHA512.
> For Postgres' purposes the recent weaknesses found i
You should read the archives of this list; there was a pretty long
thread about this a few months ago. IIRC the consensus after much debate
was that this feature would add benefit in many instances, especially on
large tables where only a small amount of data changes.
Also, I think there is value
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Andrew Dunstan
> Sent: Friday, April 22, 2005 10:46 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!!
>
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 12:06 PM
> To: Tom Lane
> Cc: Dave Held; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> Why don't we rewrite Post
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 1:22 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> And not much reward, either. To actually
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 11:42 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> Uhmmm that isn't always true. The
Russell Smith wrote:
> On Sat, 23 Apr 2005 03:14 am, Bruce Momjian wrote:
> > Hannu Krosing wrote:
> > > On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > > > See this TODO:
> > > >
> > > > * Allow data to be pulled directly from indexes
> > > >
> > > >Currently indexes do not have eno
On Sat, 23 Apr 2005 03:14 am, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > > See this TODO:
> > >
> > > * Allow data to be pulled directly from indexes
> > >
> > >Currently indexes do not have enough tuple visibility information
If it is ok with you, I'll review these for a General Bits article
and then link them up at varlena.com/GeneralBits/Tidbits
with some of the other talks I've collected.
--elein
On Fri, Apr 22, 2005 at 06:33:49PM +1000, Neil Conway wrote:
> A few hours ago, I gave a talk at linux.conf.au on the
Josh Berkus writes:
>> I've never fully understood the distinction the stats make between
>> "tuples fetched" and "tuples returned", and it's even less obvious how
>> to apply it when the index and heap operations are decoupled.
> Well, it's mainly a counter to measure how many dead rows are in
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 3:49 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> I recall saying something like this
Tom,
Hmmm ... we need to flag *something* in pg_stat_*_indexes, whether it is a new
column or the tuplefetch column. People use that view to find indexes they
can drop.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
I'm currently finding that the stats regression test fails with
bitmapped index scans enabled:
*** 62,68
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
--+--+--+--
! t| t| t| t
(1 ro
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 4:29 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> I didn't mean people can't or should
Dave Held wrote:
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 12:06 PM
To: Tom Lane
Cc: Dave Held; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!! :)
[...]
Why don't we rewrite Postgre
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> With GCC 4.x, there are new optimizations, and a while new set of
> "unknowns" that we're going to possibly get bug reports for ... and, it
> *is* a .0 major release for GCC, so there are bound to be bugs in their
> optimizer also, and I know ther
I think that's great news! If the code is written in a conforming way,
I don't see why a new release would be a cause for headaches. And if
new compiler releases *are* a cause for headaches, it doesn't give me
great confidence in the codebase.
Uhmmm that isn't always true. The switch from 2.x to
On Sat, Apr 23, 2005 at 11:58:44AM +1000, Neil Conway wrote:
> Dave Held wrote:
> >Consider inline functions. In C, you have to implement them as
> >macros
>
> No -- inline functions are in C99, and of course there have been GCC
> extensions with similar (but not identical) semantics for many ye
Fetching data from just indexes has been discussed on this list several
times before, and it has been told that this can't be done with postgres
thanks to MVCC.
But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying of
"Dave Held" <[EMAIL PROTECTED]> writes:
> Yeah, that's good news too, though it definitely helps that
> Postgres is written in C. Most of the conformance improvements
> are in the C++ front-end and the C++ Standard Library. Still
> no export though. I personally believe that projects should
> m
On Fri, 22 Apr 2005, Dave Held wrote:
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 8:56 AM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Woo hoo ... a whole new set of compiler headaches!!
:)
GCC 4.0.0 has been released.
[...]
I thin
Josh Berkus writes:
> Well, technically a bitmapscan is a different operation. So it should
> probably have its own columns. Unless you're talking about an overhaul of
> the stats views more drastic than that? If so, what?
That was basically what I was asking: do we expand all the stats su
Hannu Krosing wrote:
> On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > See this TODO:
> >
> > * Allow data to be pulled directly from indexes
> >
> > Currently indexes do not have enough tuple visibility information
> > to allow data to be pulled from the index w
On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> See this TODO:
>
> * Allow data to be pulled directly from indexes
>
> Currently indexes do not have enough tuple visibility information
> to allow data to be pulled from the index without also accessing
>
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 10:56 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> I dunno about "fundamentally faster", but
On 4/22/05, Hannu Krosing wrote:
> Fetching data from just indexes has been discussed on this list several
> times before, and it has been told that this can't be done with postgres
> thanks to MVCC.
>
> But this is true only when data is changing. In a data-warehousing
> scenario what it is often
> -Original Message-
> From: Dann Corbit [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 1:08 PM
> To: Andrew Dunstan; Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!!
>
> > From: [EMAIL PROTECTED] [mailto:
You make some good points below. I personally think C++ would be an
interesting change. It would bring additional functionality to the
language, but patch application would also have to filter C++ feature
additions along with the code changes themselves, and there is
variability in C++ compilers
On 4/22/2005 3:53 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
tuples fetched is the number of raw, possibly dead tuples fetched from
the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapshot test.
Tom,
> I've never fully understood the distinction the stats make between
> "tuples fetched" and "tuples returned", and it's even less obvious how
> to apply it when the index and heap operations are decoupled.
Well, it's mainly a counter to measure how many dead rows are in your active
data se
On Fri, 22 Apr 2005, Dave Held wrote:
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 9:46 AM
To: Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!! :)
[...]
With GCC 4.x, the
I would like to know if bitmap scans are being used on a table. I think
it's worth adding to the stats views, though I'm not sure on the best
way. For example, this means that a query on one table can now scan
multiple indexes, but it doesn't seem right to lump that in with
'traditional' index scan
Dave Held wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 3:49 PM
To: Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!! :)
[...]
I recall saying something like this whe
On Fri, 2005-04-22 at 18:34 +0300, Hannu Krosing wrote:
> Fetching data from just indexes has been discussed on this list several
> times before, and it has been told that this can't be done with postgres
> thanks to MVCC.
>
> But this is true only when data is changing. In a data-warehousing
> sc
"Dave Held" <[EMAIL PROTECTED]> writes:
> [ much snipped... ]
> And because the vast majority of C programs are also correct C++
> programs, it really wouldn't be that much effort to port the code.
And not much reward, either. To actually get benefit commensurate
with the risks involved, we'd nee
Dave Held wrote:
Consider inline functions. In C, you have to implement them as
macros
No -- inline functions are in C99, and of course there have been GCC
extensions with similar (but not identical) semantics for many years.
-Neil
---(end of broadcast)---
Dave Held wrote:
> > we'd need to do some wholesale revisions of internal APIs and
> > coding practices.
>
> No you wouldn't. You could make incremental revisions that offer a
> very gentle learning curve to C++. My suggestion is to convert the
> codebase iteratively, taking only small sure ste
Hannu,
> 1) possibility to explicitly change table status to READ-ONLY .
>
> 2) setting a flag CAN_OMIT_HEAP_CHECK after REINDEX TABLE for tables
> that are READ-ONLY
>
> 3) changing postgres planner/executor to make use of this flag, by not
> going to heap for tuples on tables where CAN_OMIT_HEAP
On Fri, Apr 22, 2005 at 11:56:13AM -0400, Tom Lane wrote:
> "Dave Held" <[EMAIL PROTECTED]> writes:
> > Yeah, that's good news too, though it definitely helps that
> > Postgres is written in C. Most of the conformance improvements
> > are in the C++ front-end and the C++ Standard Library. Still
>
"Dave Held" <[EMAIL PROTECTED]> writes:
>> I suspect most people here are already well aware of the
>> advantages and disadvantages of C++.
> That's where we disagree. In my experience, most C++ programmers
> know C, but most C programmers only know C++ through second-hand
> knowledge. And th
On 4/22/2005 3:30 PM, Tom Lane wrote:
Josh Berkus writes:
Well, technically a bitmapscan is a different operation. So it should
probably have its own columns. Unless you're talking about an overhaul of
the stats views more drastic than that? If so, what?
That was basically what I was asking
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 10:17 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> See Tom's posting ... they (redha
On Thu, Apr 21, 2005 at 01:06:13AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I'm not sure how different it is from vacuum full, though the main idea
> > is that instead of locking the table you instead work in smaller pieces
> > and don't block anything other than othe
Jochem van Dieten wrote:
On 4/22/05, Hannu Krosing wrote:
...But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying of
static historical data.
And when we get partitioning, I think many data warehouses will have
the bul
Dave Held wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 1:59 PM
To: Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!! :)
[...]
I think there are some features we could
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 1:59 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> I think there are some features we co
Jan Wieck <[EMAIL PROTECTED]> writes:
> tuples fetched is the number of raw, possibly dead tuples fetched from
> the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapshot test. It could be that the places where
All the issues brought up are why I'm not in favor of trying to do this
outside of the backend.
On Fri, Apr 22, 2005 at 11:29:27AM +0800, Qingqing Zhou wrote:
>
> > > 2) Is it possible to write a where clause that can efficiently hit only
> > > the tuples in the end of the table? If there is a w
* Eliot Simcoe ([EMAIL PROTECTED]) wrote:
> On Apr 21, 2005, at 8:59 PM, Stephen Frost wrote:
> >The intention of the 'md5' method in pg_hba.conf is to avoid having
> >the
> >password go over the network in the clear, yes. Unfortunately, this
> >pretty much requires that the database have someth
Tom,
> The reason for this appears to be that the standard stats views
> disregard tuples_fetched for tables, but tuples_fetched is the only
> counter that's getting bumped in a bitmap scan.
>
> I could probably add some code to bump tuples_returned as well,
> but I wonder whether something more d
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Interpreting PQfmod requires a rather intimate knowledge of the internal
> type implementations.
> For several types, including varchar, the typmod is rather arbitrarily
> the type's length limit plus the size of a varlena header (which appears
> to
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 22, 2005 8:56 AM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Woo hoo ... a whole new set of compiler headaches!!
> :)
>
> GCC 4.0.0 has been released.
> [...]
I think that's great new
==
Date: Fri, 22 Apr 2005 00:15:31 -0700
From: Mark Mitchell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], gcc@gcc.gnu.org
Subject: GCC 4.0.0 has been released
GCC 4.0.0 has been released.
This release is a major release, containing (among many other features) new
optimization infrastr
Great ! I recall we have repository of documents and presentations, but
don't remember where :) Josh should know, at least. Yesterday, I gave a
45 minutes talk at annual conference "Corporative Databases" in Moscow, Russian
Academy of Science and also have slides, a paper (both in Russian) I'd li
On Apr 21, 2005, at 8:59 PM, Stephen Frost wrote:
* Paul Tillotson ([EMAIL PROTECTED]) wrote:
Maybe I misunderstood, but I thought that others were saying that, if
someone gets the contents of pg_shadow, then
- if you use only "password" in your pg_hba.conf, he has to break
one of
the hashes fir
On 2005-04-22, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I'm trying to find out, from a client, how many characters will fit in a
> varchar field
> Problem is that when I do "PQfmod" on a varchar field defined as
> "varchar(20)", PQfmod returns "24".
Interpreting PQfmod requires
Hi list,
I'm trying to find out, from a client, how many characters will fit in a
varchar field
(http://pgfoundry.org/tracker/index.php?func=detail&aid=1000286&group_id=185&atid=394).
Problem is that when I do "PQfmod" on a varchar field defined as
"varchar(20)", PQfmod returns "24".
Now,
A few hours ago, I gave a talk at linux.conf.au on the internals of the
PostgreSQL query optimizer. The slides are here:
http://neilc.treehou.se/optimizer.pdf
Corrections or suggestions for improvement are welcome. The LaTeX source
is also available if anyone wants it. If you'd like to use t
65 matches
Mail list logo
