Greetings to all,
I use to run below query on my Postgres Database Server very often :
select
m.doc_category,p.heading,l.lat,l.lon,p.crawled_page_url,p.category,p.dt_stamp,p.crawled_page_id,p.content
from loc_context_demo l,page_content_demo p,metadata_demo m
where l.source_id=p.crawled_page_
Resending. Hit the send button too soon.
Use apt-get to install
sudo apt-get install libreadline-dev
sudo apt-get install zlib1g-dev
and other dependencies mentioned in the source distribution INSTALL file.
ln -s /usr/bin/make /usr/bin/gmake
This will give you gmake which would already be in
Use apt-get to install
sudo apt-get install libreadline-dev
and zlib1g-dev. Then do a symbolic link for make to gmake.
On Sun, Feb 27, 2011 at 11:39 PM, Selva manickaraja wrote:
> Yes, true now it looks like pg-general. I started out this discussion
> because I couldn't get Performance Testin
Monday, February 28, 2011, 7:39:30 AM you wrote:
> OK, I did exactly to move to the top of the directory and run the
> ./configure first. Everything work until the last time it reports error
> now
> --
Yes, true now it looks like pg-general. I started out this discussion
because I couldn't get Performance Testing done. But looks like the
performance cannot be done due to the tool cannot be built...:) and all
evils are getting unleashed from this..
OK, I did exactly to move to the top of the dire
On 28/02/11 18:09, Selva manickaraja wrote:
As mentioned in the documentation, I went to the directory
src/test/regress and ran the command. It gives the error
GNUmakefile:15: ../../../src/Makefile.global: No such file or directory
GNUmakefile:80: /src/Makefile.shlib: No such file or directory
Tom,
The query which you gave returns me 0 rows.
select ctid,xmin,xmax,* from pg_index where indexrelid in
(select indexrelid from pg_index group by 1 having count(*)>1);
Regards,
Bhakti
On Sat, Feb 26, 2011 at 10:55 PM, Tom Lane wrote:
> Bhakti Ghatkar writes:
> > We were running
As mentioned in the documentation, I went to the directory src/test/regress
and ran the command. It gives the error
GNUmakefile:15: ../../../src/Makefile.global: No such file or directory
GNUmakefile:80: /src/Makefile.shlib: No such file or directory
make: *** No rule to make target `/src/Makefile
On 28/02/11 16:26, Selva manickaraja wrote:
We have installed PostgreSQL9 and setup standby(s). Now we have to
test the performance before we migrate all the data from Informix. The
PostgreSQL9 that we installed is the Linux version from EnterpriseDB
which runs on Red Hat. The documentation
Hi,
We have installed PostgreSQL9 and setup standby(s). Now we have to test the
performance before we migrate all the data from Informix. The PostgreSQL9
that we installed is the Linux version from EnterpriseDB which runs on Red
Hat. The documentation on PostgreSQL website shows that we have gmake
27 лютого 2011 р. 19:59 Robert Haas написав:
> 2011/2/4 Віталій Тимчишин :
> > Hi, all.
> > All this optimizer vs hint thread reminded me about crazy idea that got
> to
> > my head some time ago.
> > I currently has two problems with postgresql optimizer
> > 1) Dictionary tables. Very usual thing
Robert Haas writes:
> On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
>> I'm not saying that PostgreSQL couldn't do better on this kind of case,
>> but that doing better is a major project, not a minor one.
> Specifically, the problem is that x = 4.0, where x is an integer, is
> defined to me
On Mon, Feb 7, 2011 at 7:14 PM, Sylvain Rabot wrote:
> First I would like to know if there is more advantage than overhead to
> split an index in several ones using conditions
I don't see why that would be any better than just defining one big index.
> e.g. doing :
>
> CREATE INDEX directory_id_
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
> Laszlo,
>
>> Which is silly. I think that PostgreSQL converts the int side to a
>> float, and then compares them.
>>
>> It would be better to do this, for each item in the loop:
>>
>> * evaluate the right side (which is float)
>> * tell
2011/2/4 Віталій Тимчишин :
> Hi, all.
> All this optimizer vs hint thread reminded me about crazy idea that got to
> my head some time ago.
> I currently has two problems with postgresql optimizer
> 1) Dictionary tables. Very usual thing is something like "select * from
> big_table where distionar
15 matches
Mail list logo
