On Fri, Aug 7, 2009 at 5:24 PM, Culley Harrelson wrote:
> Hi Everyone,
>
> I manage a freeBSD server that is dedicated to postgresql. The
> machine has 4 gigs of ram and there is a single database powering a
> web application that is hosted on a neighboring machine. The web
> application is mostl
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Now that we have SQL-level CONNECT privilege, I wonder just how much
> >> functionality would be lost if we got rid of the flat files and told
> >> people they had to use CONNECT to do any per-user or per-database
> >> access control
Alvaro Herrera writes:
> Tom Lane wrote:
>> In some sense this is a bootstrap problem: what does it take to get to
>> the point of being able to read pg_database and its indexes? That is
>> necessarily not dependent on the particular database we want to join.
>> Maybe we could solve it by having
Tom Lane wrote:
> In some sense this is a bootstrap problem: what does it take to get to
> the point of being able to read pg_database and its indexes? That is
> necessarily not dependent on the particular database we want to join.
> Maybe we could solve it by having the relcache write a "global"
Alvaro Herrera writes:
> Tom Lane wrote:
>> So on third thought, Alvaro's right: the only real solution here is to
>> adopt a more efficient representation of the flat files. Maybe some
>> sort of simple hashtable arrangement would work. (Rendering them not so
>> flat anymore...)
> As long as t
Tom Lane wrote:
> Actually, I had forgotten that we were using the pg_database flatfile
> for purposes other than authentication checks. In particular, we need
> it during backend startup to map from database name to database OID,
> without which it's impossible to locate the system catalogs for
I wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> ... I don't remember exactly what we do with the
>>> flat-file contents.
>> Maybe what we need is not to get rid of the flat files, but to speed
>> them up. If we're worried about speed in the pg_authid flatfile, and
>> come up with a solu
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... I don't remember exactly what we do with the
>> flat-file contents.
> Maybe what we need is not to get rid of the flat files, but to speed
> them up. If we're worried about speed in the pg_authid flatfile, and
> come up with a solution to that prob
Tom Lane wrote:
> Well, it's a TO-THINK-ABOUT anyway. I think the appropriate next step
> would not be to write code, but to do a detailed investigation of what
> would be gained or lost. I don't remember exactly what we do with the
> flat-file contents.
Maybe what we need is not to get rid of
On Saturday 08 August 2009 08:02:47 Fizu wrote:
>-> Index Scan using country_ranking_user_idx on "user"
> (cost=0.00..6.49 rows=1 width=145) (actual time=0.023..57.633
> rows=57309 loops=1)
> Index Cond: (country_id = 1)
The planner is expecting one user with
Bruce Momjian writes:
> Tom Lane wrote:
>> Now that we have SQL-level CONNECT privilege, I wonder just how much
>> functionality would be lost if we got rid of the flat files and told
>> people they had to use CONNECT to do any per-user or per-database
>> access control.
>>
>> The main point I ca
I don't see how on any recent hardware, random access to RAM is slower
than
sequential from disk. RAM access, random or not, is measured in
GB/sec...
I don't think anybody's arguing that.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2795&p=5
These guys mention about 50 ns memory
12 matches
Mail list logo
