Hi all,
last week Josh Berkus point my attenction
( see post Wrong plan or what )
to the
fact that in this select:
select *
from user_logs ul,
user_data ud,
class_default cd
where
ul.id_user = ud.id_user and
ud.id_class = cd.id_class and
cd.id_provider = 39;
The planner
what you say is that the index is not effective because of its size, but it would still be used *if* the conditions are right... In this case, I care about performance, not space.
But what you say about the index not being good because 100% of rows match the condition confirms what I suspecte
Franco,
> CREATE INDEX sales_k1 ON sales(clientId, branchId, productId,
> employeeId, saleDate, price, qty);
A 7-column index is unlikely to be effective -- the index will be almost as
large as the table. Try indexing only the first 3-4 columns instead.
> I want to make a function that retu
On Fri, 2003-07-25 at 11:52, Franco Bruno Borghesi wrote:
[snip]
>
>
> Will findSale() in the future, when I have *many* rows still use the
> index when only the first couple of
> arguments are passed to the function?
> If not, should I create more indexes (and functions) for each possible
> argu
On Fri, 2003-07-25 at 11:13, Josh Berkus wrote:
> Folks,
>
> > Since PG doesn't have active-active clustering, that's out, but since
> > the database will be very static, why not have, say 8 machines, each
> > with it's own copy of the database? (Since there are so few updates,
> > you feed the u
Hi everyone.
I have created a simplified example of a real case, to show you what I'm tryng to do. I have
a table, like this:
CREATE TABLE sales (
saleId SERIAL,
clientId INTEGER,
branchId INTEGER,
productId INTEGER,
employeeId INTEGER,
saleDate DATE,
price NUMERIC(12, 2)
Folks,
> Since PG doesn't have active-active clustering, that's out, but since
> the database will be very static, why not have, say 8 machines, each
> with it's own copy of the database? (Since there are so few updates,
> you feed the updates to a litle Perl app that then makes the changes
> on
On 25 Jul 2003 at 18:41, Kasim Oztoprak wrote:
> what exactly do you mean from a pilot program?
Like get a quad CPU box, load the data and ask only 10 operators to test the
system..
Beta testing basically..
Bye
Shridhar
--
The man on tops walks a lonely street; the "chain" of command is often
On 25 Jul 2003 17:13 EEST you wrote:
> On 25 Jul 2003 at 16:38, Kasim Oztoprak wrote:
> > this is kind of directory assistance application. actually the select statements
> > are not
> > very complex. the database contain 25 million subscriber records and the operators
> > searches
> > for the
On Fri, 2003-07-25 at 11:38, Kasim Oztoprak wrote:
> On 24 Jul 2003 23:25 EEST you wrote:
>
> > On Thu, 2003-07-24 at 13:25, Kasim Oztoprak wrote:
> > > On 24 Jul 2003 17:08 EEST you wrote:
> > >
> > > > On 24 Jul 2003 at 15:54, Kasim Oztoprak wrote:
> > [snip]
> > >
> > > we do not have memory
On 24 Jul 2003 at 9:42, William Yu wrote:
> As far as I can tell, the performance impact seems to be minimal.
> There's a periodic storm of replication updates in cases where there's
> mass updates sync last resync. But if you have mostly reads and few
> writes, you shouldn't see this situation
On 25 Jul 2003 at 16:38, Kasim Oztoprak wrote:
> this is kind of directory assistance application. actually the select statements are
> not
> very complex. the database contain 25 million subscriber records and the operators
> searches
> for the subscriber numbers or addresses. there are not muc
On 24 Jul 2003 23:25 EEST you wrote:
> On Thu, 2003-07-24 at 13:25, Kasim Oztoprak wrote:
> > On 24 Jul 2003 17:08 EEST you wrote:
> >
> > > On 24 Jul 2003 at 15:54, Kasim Oztoprak wrote:
> [snip]
> >
> > we do not have memory problem or disk problems. as I have seen in the list the
> > best wa
13 matches
Mail list logo
