Almost all of the 8k queries per second that are hitting our database
are generated by a web development framework's ORM (Django), and some
of the syntax there is quite mad. Possibly the worst tic exhibited by
the translation layer is that if you filter a query on an object by
more than one propert
Frank Jördens wrote:
Our Django experts are telling me that it is probably not practical to
fix in the ORM, as it seems to be structural (anyway not fixable for
us in the near term). Hence I am wondering if anyone has an idea as to
how to make the planner smarter about such weirdness (or brokenne
Frank Joerdens wrote:
On Fri, May 22, 2009 at 10:56 AM, Richard Huxton wrote:
[...]
Are you sure it wouldn't be easier to hire a Python guru for a couple of
days and have him/her hack the ORM to make it less, um, "simplistic"?
Not sure. :) Your arguments make eminent sense to me. I am not exa
On Fri, 2009-05-22 at 10:33 +0100, Frank Jördens wrote:
> Almost all of the 8k queries per second that are hitting our database
> are generated by a web development framework's ORM (Django), and some
> of the syntax there is quite mad. Possibly the worst tic exhibited by
> the translation layer is
possibly this answers my question, and what i am doing is indeed the most
appropriate?
"Databases are physically separated and access control is managed at the
connection level."
from 8.3 docs, section 20.1
thanks,
Isaac
On Fri, May 22, 2009 at 2:37 AM, Isaac Dover wrote:
> Hello, to this poi
Hello
I have frequently encountered the need of combining two tables into one.
First, please take a look at the following table setups...
CREATE TABLE topics (
id SERIAL PRIMARY KEY,
topic TEXT NOT NULL
);
CREATE TABLE messages (
id SERIAL PRIMARY KEY,
topic INTEGER REFERENCES topics(
On Friday 22 May 2009 6:48:43 am Richard Ekblom wrote:
> Hello
>
> I have frequently encountered the need of combining two tables into one.
> First, please take a look at the following table setups...
>
> CREATE TABLE topics (
>id SERIAL PRIMARY KEY,
>topic TEXT NOT NULL
> );
>
> CREATE TAB
Dear Richard Ekblom,
I think Mr. Adrian Klaver gave you the solution. Mine is the similar solution
SELECT message.id,topic.topic,message.message
FROM topics, messages
WHERE message.topic=topic.id order by message.id;
After executing this query you will get the following:
id | top
Good morning,
When there are lots of views and complicated dependencies, it is not
easy to alter column from varchar(a) to varchar(b).
Is it possible when defining a view, adding cascade or some other key
word(s) to allow column type change?
When column1 is changed, all related views' colum
I guess this is pretty much the same
as doing
SELECT message.id,topic.topic,message.message
FROM topics
JOIN messages
ON topics.id = message.topic
ORDER BY message.ID
Ain't I right?
Best,
Oliveiros
- Original Message -
From: James Kitambara
To: Richard Ekblom
Cc: pgsql-s
if you want topics listed which don't yet have messages try
select t.id, t.topic, m.id, m.message from topics t left join messages m on
m.topic = t.id;
On Fri, May 22, 2009 at 8:47 AM, James Kitambara wrote:
> Dear Richard Ekblom,
>
> I think Mr. Adrian Klaver gave you the solution. Mine is the
Isaac Dover writes:
>> As far as i can tell,
>> pg_hba.conf is the only manner in which to prevent users from connecting to
>> other users' databases. I've restricted roles to connecting only using
>> sameuser:
>>
>> host sameuser all 192.168.168.0/24 md5
In recent releases (certainly 8.3) the b
thank you _SO_ much. I'm not sure how I overlooked that, but it is far
easier to manage using connect. I'm assuming that even if tables have public
privileges granted, that they are not visible to people not granted connect
privileges to the database?
Thanks,
Isaac
On Fri, May 22, 2009 at 12:31 P
Isaac Dover writes:
> thank you _SO_ much. I'm not sure how I overlooked that, but it is far
> easier to manage using connect. I'm assuming that even if tables have public
> privileges granted, that they are not visible to people not granted connect
> privileges to the database?
Right, if you can
Two tables, each contains more than hundreds of thousands records. Is
there any efficiency differences between (1) and (2)?
(1) T1 inner join T2 using (c1, c2)
(2) T1 left join T2 using (c1, c2) where c2 is not null
Thanks,
--
Lu Ying
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql
On May 22, 2009, at 1:51 PM, Emi Lu wrote:
Two tables, each contains more than hundreds of thousands records.
Is there any efficiency differences between (1) and (2)?
(1) T1 inner join T2 using (c1, c2)
(2) T1 left join T2 using (c1, c2) where c2 is not null
Yes, stick with the first. I
16 matches
Mail list logo
