> Could you please provide below information.
>
> How to change standard_conforming_strings value of postgresql.conf?
I would not change that option. You should rather stick to standard conforming
strings and fix your query.
That can be done through a simple (and automated) search & replace.
On Thu, 18 Jun 2015 07:29:37 +
"Yogesh. Sharma" wrote:
> HI Everyone,
>
> Below DB query is showing below error on postgresql9.3.
> SELECT '\'' || t2.name || '\'', '\'' || t1.phone_number || '\'', '\'' ||
> t1.details || '\'', '\'' || t1.description || '\'', '\'' || (CASE WHEN
> t1.s_id IS
Fantastic resource. Thanks for this!
On Tue, Oct 30, 2012 at 3:16 PM, Adrian Klaver wrote:
> On 10/30/2012 04:07 AM, RAJDEEP SARDAR wrote:
>
>> Dear All,
>>
>> I am a Mtech Student,IIT Bombay,India.
>>
>> I am having a database course project where I need to make some
>> modification in postgresq
On 10/30/2012 04:07 AM, RAJDEEP SARDAR wrote:
Dear All,
I am a Mtech Student,IIT Bombay,India.
I am having a database course project where I need to make some
modification in postgresql.
currently,my objective is to find how a select query runs in
postgresql.I have some knowledge related to pa
Hi,
Sorry for the late response on this.
On Wed, Aug 31, 2011 at 09:40, Tomas Vondra wrote:
> On 31 Srpen 2011, 1:07, Dan Scott wrote:
>> On Tue, Aug 30, 2011 at 13:52, Daniel Verite
>> wrote:
>>> Dan Scott wrote:
>>>
the insert process is unable to insert new rows into the database
On 31 Srpen 2011, 1:07, Dan Scott wrote:
> On Tue, Aug 30, 2011 at 13:52, Daniel Verite
> wrote:
>> Dan Scott wrote:
>>
>>> the insert process is unable to insert new rows into the database
>>
>> You should probably provide the error message on insert or otherwise
>> describe
>> how it's no
On Tue, Aug 30, 2011 at 13:21, Scott Ribe wrote:
> On Aug 30, 2011, at 8:22 AM, Dan Scott wrote:
>
>> Perhaps because I'm locking the table with my query?
>
> Do you mean you're explicitly locking the table? If so, why???
No, not explicitly. I just thought of it as a possible explanation. If
read
On Tue, Aug 30, 2011 at 13:52, Daniel Verite wrote:
> Dan Scott wrote:
>
>> the insert process is unable to insert new rows into the database
>
> You should probably provide the error message on insert or otherwise describe
> how it's not working. Normally reading does not unintentionally p
Dan Scott wrote:
> the insert process is unable to insert new rows into the database
You should probably provide the error message on insert or otherwise describe
how it's not working. Normally reading does not unintentionally prevent
writing in a concurrent session.
Best regards,
--
Da
On Aug 30, 2011, at 8:22 AM, Dan Scott wrote:
> Perhaps because I'm locking the table with my query?
Do you mean you're explicitly locking the table? If so, why???
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing
I am answering just for the sake of answering your questions.
What hubert depesz lubaczewski suggested had fixed the problem i had.
I have other queries that need event_id to be the clustered index
Veh_id is spread all over the table. (for veh_id 3 there are no records)
Due to the spread of reco
Thanks, it did help. Now queries run in zero time.
I had thought of doing thatbut since the same configuration was working
ok on MSSQL I thought it should also here.
Now with that index the server query times are a lot faster than MSSQL
without it.
Since it is working I will leave it like that
On 27 Jan 2011, at 15:04, Michael Kemanetzis wrote:
> Hello, I'm experiencing a strange behavior running a simple select query on a
> table that has about 12 million rows. Specifically, changing the "LIMIT"
> value seems to change the execution plan but the result in one of the cases
> is unjus
On Thu, Jan 27, 2011 at 04:04:02PM +0200, Michael Kemanetzis wrote:
> Hello, I'm experiencing a strange behavior running a simple select query on
> a table that has about 12 million rows. Specifically, changing the "LIMIT"
> value seems to change the execution plan but the result in one of the case
-Original Message-
From: Jeff Davis [mailto:pg...@j-davis.com]
Sent: Monday, August 30, 2010 5:23 PM
To: Yosef Haas
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] select query on Dates stored as varchar
On Mon, 2010-08-30 at 16:32 -0400, Yosef Haas wrote:
> I have a table (tra
On Mon, 2010-08-30 at 16:32 -0400, Yosef Haas wrote:
> I have a table (transactions) with an order_date field that is
> varchar(32). The data looks like this:
>
>
>
> order_date
>
> ---
>
> 20100623 02:16:40
>
> 20100623 04:32:41
>
> 20100625 04:18:53
>
> 20100625 07:53
t; -Original Message-
> From: Pavel Stehule [mailto:pavel.steh...@gmail.com]
> Sent: Monday, August 30, 2010 4:45 PM
> To: Yosef Haas
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] select query on Dates stored as varchar
>
> Hello
>
> 2010/8/30 Yosef Haas :
&
2010/8/30 Scott Marlowe :
> On Mon, Aug 30, 2010 at 2:53 PM, Yosef Haas wrote:
>> I know it would be best to change the data type of the column (I didn't
>> initially create the table), but doing so would be require changes to
>> several application that use it and I'd like to avoid that if possib
On Mon, Aug 30, 2010 at 2:53 PM, Yosef Haas wrote:
> I know it would be best to change the data type of the column (I didn't
> initially create the table), but doing so would be require changes to
> several application that use it and I'd like to avoid that if possible.
1. Most of those changes w
rom: Pavel Stehule [mailto:pavel.steh...@gmail.com]
Sent: Monday, August 30, 2010 4:45 PM
To: Yosef Haas
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] select query on Dates stored as varchar
Hello
2010/8/30 Yosef Haas :
> I have a table (transactions) with an order_date field that
Hello
2010/8/30 Yosef Haas :
> I have a table (transactions) with an order_date field that is varchar(32).
> The data looks like this:
>
>
>
> order_date
>
> ---
>
> 20100623 02:16:40
>
> 20100623 04:32:41
>
> 20100625 04:18:53
>
> 20100625 07:53:24
>
>
>
> In my current databa
If you put this in the application, you could do something such as:
my @manufacturers = fetch("select manufacturer_no, name from
manufacturers");
my @select_fields = ('product_no');
foreach my $manufacturer (@manufacturers) {
my $manuf_no = $manufacturer->{manufacturer_no};
my $name = $man
Teemu Juntunen wrote:
Hi Experts,
is threre any way to SELECT values in columns instead of rows? For
example select products and their manufacters in the followin way:
product1; manufacturer1; manufacturer2;,,, manufacturerN
product2; manufacturer3;
product3; manufacturer1;.. manufacturerN-
Bright D.L. wrote:
>Once step 6 completes, can psql see the data?
Yes, P1 makes sure and is able to see the data before sending Packet to
P2.
Not P1, but psql. If you can see the data from psql, then your problem
has to be in P2. If you can't see the data from psql, then P1 is the
probl
"Bright D.L." <[EMAIL PROTECTED]> writes:
> P1 did commit its insertion and verified it by successfully querying the
> last inserted data, before sending the TCP packet - the trigger - to P2
The fact that P1 can see data it inserted is no proof at all that it's
committed its transaction. I think
>> Processes P1 and P2 are executables developed in VC++. These are the
>> steps performed by P1 before sending the TCP packet (which acts as a
>> trigger) to P2.
>>
>> 1) Create an insertion query
>> 2) Execute the query
>> 3) Execute a 'Commit' command
> 4) Repeat 2 and 3 how many ever times need
Bright D.L. wrote:
Processes P1 and P2 are executables developed in VC++. These are the
steps performed by P1 before sending the TCP packet (which acts as a
trigger) to P2.
1) Create an insertion query
2) Execute the query
3) Execute a 'Commit' command
4) Repeat 2 and 3 how many ever times neede
>hi,
>have a look at transaction isolation in docs
Thanks TM. I checked the isolation level of the DB and it is "read
committed". May be I will change it to 'Serializable' and check whether
that helps.
>/tm
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
>> The scenario:
>> There are two separate processes ? one (P1) inserting
(not
>> updating) data to a table at a high rate (around one record in 10ms)
and
>> another (P2) selecting the data from the same table for further
>>processing. P1
>> and P2 use separate connection to the Databas
Thank you Craig,
>At a guess: transactional visibility. P1 will have not yet committed
its
>transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
>defaults to the READ COMMITTED isolation level and does not offer READ
>UNCOMMITTED for those rare situations where you might want it.
Bright D.L. wrote:
> I would like to know why P1 can retrieve the data from the table while
> P2 can't.
At a guess: transactional visibility. P1 will have not yet committed its
transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
defaults to the READ COMMITTED isolation level an
am Wed, dem 09.07.2008, um 16:32:11 +0800 mailte Bright D.L. folgendes:
> The scenario:
> There are two separate processes ? one (P1) inserting (not
> updating) data to a table at a high rate (around one record in 10ms) and
> another (P2) selecting the data from the same table for furt
hi,
have a look at transaction isolation in docs
/tm
begin:vcard
fn:Thomas Markus
n:Markus;Thomas
org:proventis GmbH
adr:;;Zimmerstr. 79-80;Berlin;Berlin;10117;Germany
email;internet:[EMAIL PROTECTED]
tel;work:+49 30 29 36 399 22
x-mozilla-html:FALSE
url:http://www.proventis.net
version:2.1
end
Ashish Karalkar wrote:
Hello List,
I am having list of tables , what I want to do is to
filter this list of table for a particular value of
its column, the column which i will be searching is
common accross all tables in list
any clues??
Something like
SELECT * FROM
(
SELECT col1,co
Yes , that was the case indeed. I disabled seq scan and it used the index. And
the cost was higher than seq scan.
Thanks a lot for all your replies.
With warm regards.
Vivek J. Joshi.
[EMAIL PROTECTED]
Trikon Electronics Pvt. Ltd.
All science is either physics or stamp collecting.
On 12/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The index was created before the table was populated. There are 3 rows in
the table for 3 different users. Now when I do a
postgresql will not use index scan for table with 3 rows in it. it is way
faster to use seq scan on it.
depesz
am Sat, dem 02.12.2006, um 16:35:47 +0530 mailte [EMAIL PROTECTED] folgendes:
>
> The index was created before the table was populated. There are 3 rows
> in the table for 3 different users. Now when I do a
In this case, with only 3 rows, it is much cheaper to do a seq-scan
instead a index-scan
Vivek --
If you could let people know what version of postgres, and which OS, it might
help.
A guess: the planner sees that there are very few rows and decides that a
sequential scan is faster (this is because a sequential scan on a table with
only a few rows is probably done in one operation;
38 matches
Mail list logo
