Hey, that trick with session_user is great! :-) Thank you all very much,
this will certainly help.
---
Petr Kavan
Database Development
- Original Message -
From: "John Arbash Meinel" <[EMAIL PROTECTED]>
To: "Petr Kavan" <[EMAIL
One little thing. Did you shutdown sql2000 while testing postgresql? Remember
that postgresql uses system cache. Sql2000 uses a large part of memory as
buffer and it will not be available to operating system. I must say that,
probably, results will be the same, but it will be a better test.
> I
On Sun, Aug 14, 2005 at 09:18:45PM -0400, Tom Lane wrote:
> Not really. There's been some speculation about implementing index
> "skip search" --- once you've verified there's at least one visible
> row of a given index value, tell the index to skip to the next different
> value instead of handing
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> To me, it looks like he'll get 88 rows, not 3.2M. Surely we must be able to
> do something better than a full sequential scan in this case?
Not really. There's been some speculation about implementing index
"skip search" --- once you've verifie
Steinar H. Gunderson wrote:
>On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote:
>
>
>>My guess is that this is part of a larger query. There isn't really much
>>you can do. If you want all 3.2M rows, then you have to wait for them to
>>be pulled in.
>>
>>
>
>To me, it looks
On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote:
> If you are just trying to determine what the unique entries are for cod,
> you probably are better off doing some normalization, and keeping a
> separate table of cod values.
Pah, I missed this part of the e-mail -- you can igno
On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote:
> My guess is that this is part of a larger query. There isn't really much
> you can do. If you want all 3.2M rows, then you have to wait for them to
> be pulled in.
To me, it looks like he'll get 88 rows, not 3.2M. Surely we must
"Petr Kavan" <[EMAIL PROTECTED]> writes:
> Possibility is to create a view for each employee that chooses only his data
> and give employee privileges to this view. But I am not sure if such number
> of views does not have some performance drawbacks or even if postgre can
> support it (I expect
Stéphane COEZ wrote:
>Hi,
>
>I have a perfomance issue :
>
>I run PG (8.0.3) and SQLServer2000 on a Windows2000 Server (P4 1,5Ghz 512Mo)
>I have a table (320 rows) and I run this single query :
>
>select cod from mytable group by cod
>I have an index on cod (char(4) - 88 different values)
>
>P
Petr Kavan wrote:
> I have database of company data, and some of them is table of
> information about employees. I need each employee to have access only
> to his own row. Postgre cannot do this by system of privileges,
> because that can give privileges only to whole tables.
>
> Possibility is to
Hi Paul,
I was passed your message... regarding DSS workload with Postgres on Solaris.
(I am not in the alias).
Performance is relative to your workload. Can you actually send us what you are
doing in your queries, updates etc?
I have been running few tests myself and here are my rules of thum
Hi,
I have a perfomance issue :
I run PG (8.0.3) and SQLServer2000 on a Windows2000 Server (P4 1,5Ghz 512Mo)
I have a table (320 rows) and I run this single query :
select cod from mytable group by cod
I have an index on cod (char(4) - 88 different values)
PG = ~ 20 sec.
SQLServer = < 8 sec
I have database of company data, and some of them is table of information
about employees. I need each employee to have access only to his own row.
Postgre cannot do this by system of privileges, because that can give
privileges only to whole tables.
Possibility is to create a view for each em
13 matches
Mail list logo